Micky wrote:

I dug out some old bat files and looked at them and
Return /b
is what I had in mind. I know it kept the CMD window open with bat
files I used last summer. I wanted the window to stay open because I
wasn't done yet.

I have never heard of "return" and that's going back to Win3.1x days.
It is probably some software you installed. It is not an internal
command within cmd.exe nor is it a program supplied with Windows.

Just put pause at the end of the .bat file as Rodney already suggested.
pause just outputs "Press any key to continue ..." If you want
something more descriptive, use echo following by pause (with the output
of pause hidden), as in:

echo whateverPromptYouWantToSee
pause nul

I added the exit command at the end because I suggested to reference the
..bat files via shortcut, and leaving the console window open could be a
nuisance. If you open a console (cmd.exe) which opens a console window
and want that window to stay open after running the .bat files inside of
it, remove the exit command.

Because the .bat files call the sc.exe (service controller) program to
alter the state of NT services, you need to either configure the
shortcuts (that run the .bat files) to run under admin mode (or allow
the .bat file to commit its actions when the UAC prompt appears) or load
a console (cmd.exe) that runs in admin mode. If you run the .bat files
inside a console without admin privileges, you see a bunch of errors.
By using shortcuts to the .bat files, I get the UAC prompt and allow the
batch file to run.

What did you expect to see from the output of the batch files? That
output will not verify that services have actually stopped and were
disabled. All you get is succeed and fail statuses. For example, if
you run wu-disable.bat twice, the 2nd is guaranteed to show errors but
that's because you're trying to disable services that have already been
disabled. That the command succeeded doesn't mean the service actually
changed state as planned. The sc.exe command issues requests. Those
requests succeed or fail. There is no waiting around to find out if the
services actually did change states. The command is asynchronous. You
would have to wait for awhile to wait for the services to actually stop
before you later test for success.

Unless I add "sc.exe query BITS" and "sc.exe query wuausrv" to the end
of the batch file, you won't find the stdout from the .bat file to be
very useful. Besides, that would only show the services are stopped,
not that they are disabled. I would have to add:

after stopping and disabling BITS, or after enabling BITS:
sleep
sc.exe query BITS
sc.exe qc BITS
after stopping and disabling wuausrv, or after enabling wuausrv:
sleep
sc.exe query wuausrv
sc.exe qc wuausrv

where sleep uses the timeout command (internal to cmd.exe) or the
old "ping -w timeout localhost" trick.

Then you could see both the current state of the services and that they
were disabled - but they may have not changed yet even after the sleep
period. Services can change state very fast or very slow. So you can
either sleep a very long time and then check service state or use a
for-loop to keep polling for change (and parse the output to detect
state) with a shorter sleep where the for-loop exits immediately when
the state changes to the specified state (or eventually errors after a
max loop count figuring the service is not responding). I wasn't going
to that extravagance of scripting for simple stop and disable/enable
directives. That would also make the user sit around watching the
stdout in the console to determine (if they understood the output)
whether the sc.exe command worked or not.

That is a lot of output to look at just to verify that the .bat files
did indeed disable/enable the services. I have yet for these simple
batch files to fail doing what they're told to do -- unless you make the
mistake of not running them under admin privileges. With shortcuts to
the .bat files, I get a UAC prompt that ensures they run with admin
privileges. If I run them inside a console (cmd.exe) with its window
left open, it becomes apparent from the errors that I did not load
cmd.exe with admin privileges; however, the output is no value to me so
I never run them that way.

Yes, during testing, you could run cmd.exe -- with admin privileges --
to see the output of the sc.exe command. However, since your batch
script skills are weak (didn't know to remove 'exit' to watch without
closing the shell, didn't know why the console window disappeared when
using Start - Run, didn't know about adding a pause, didn't know sc.exe
issues asynchronous requests), I doubt you would understand the output
of sc.exe, anyway, or want to get into scripting that employs a fixed
sleep or a for-loop and variable parsing to wait until the service
states actually changed. By the time you click on the shortcut to
wu-disable.bat and then click on the shortcut to run Windows Update, the
services should've already been enabled and ready. If not, the WU
client will tell you it can't run. After WU is done, you don't care how
long it takes for the services to stop and get disabled.

I could add more logic into the script to ensure a service was actually
stopped before I disabled it, or to ensure a service got enabled before
starting it or changing its startup state but, so far, haven't need that
extra logic to accomodate that sc.exe issue asynchronous requests (sc
asks for a change, sc exits, change happens later whether fast or slow).