I have a "setup" script which I run in the morning which starts all the programs that I need. Now some of those need additional setup of the environment, so I need to wrap them in small BAT scripts.

How do I run such a script on Windows XP in the background?

CALL env-script.bat runs it synchronously, i.e. the setup script can continue only after the command in the env-script has terminated.

START/B env-script.bat runs another instance of CMD.exe in the same command prompt, leaving it in a really messy state (I see the output of the nested CMD.exe, keyboard is dead for a while, script is not executed).

START/B CMD env-script.bat yields the same result. None of the flags in CMD seem to match my bill.

Standard, inline approach: (i.e. behaviour you'd get when using & in Linux)

START /B CMD /C CALL "foo.bat" [args [...]]

Notes: 1. CALL is paired with the .bat file because that where it usually goes.. (i.e. This is just an extension to the CMD /C CALL "foo.bat" form to make it asynchronous. Usually, it's required to correctly get exit codes, but that's a non-issue here.); 2. Double quotes around the .bat file is only needed if the name contains spaces. (The name could be a path in which case there's more likelihood of that.).

If you don't want the output:

START /B CMD /C CALL "foo.bat" [args [...]] >NUL 2>&1

If you want the bat to be run on an independent console: (i.e. another window)

START CMD /C CALL "foo.bat" [args [...]]

If you want the other window to hang around afterwards:

START CMD /K CALL "foo.bat" [args [...]]

Note: This is actually poor form unless you have users that specifically want to use the opened window as a normal console. If you just want the window to stick around in order to see the output, it's better off putting a PAUSE at the end of the bat file. Or even yet, add ^& PAUSE after the command line:

& is an "and then" (terminology?) operator. (e.g. cmd1 & cmd2 means do "cmd1" and then "cmd2". Unlike the && operator, execution of "cmd2" doesn't depend on the successful exit of "cmd1".) The ^ escapes the & so that it goes into CMD's arguments instead of being consumed and run by the same console that ran START.
–
antakDec 8 '11 at 1:56

This is very helpful, thanks. I was just about to port some scripts to Linux, because other guides to start and cmd didn't give the full functionality I sought. Your answer nails it.
–
IteratorDec 17 '11 at 1:34

3

If you don't want the output then the redirection must be escaped so that it gets passed to CMD. Also CALL is not needed: START /B "" CMD /C "foo.bat" [args [...]] ^>nul 2^>^&1
–
dbenhamJul 30 '12 at 1:21

1

@dbenham: Although what you're saying makes sense, START /B "" CMD /C PING 127.0.0.1 >NUL seems to work regardless and nothing is output. (Probably because CMD inherits START's I/O handles.) I guess the difference is if you want to keep START's (error) output intact, which is probably a good idea. CALL is just there because I felt it's a good practice to keep. (i.e. Not using CALL for synchronous bat calls will result in unpredictable exit codes, so I consistently pair bat calls with CALL even when it doesn't strictly apply, such as in this case.)
–
antakJul 30 '12 at 8:01

Since START is the only way to execute something in the background from a CMD script, I would recommend you keep using it. Instead of the /B modifier, try /MIN so the newly created window won't bother you. Also, you can set the priority to something lower with /LOW or /BELOWNORMAL, which should improve your system responsiveness.

Until PowerShell is available 100% - C# is really overkill.
–
jimMar 16 '09 at 12:42

1

Aaron: The C# compiler is included in the .NET Framework 2, so you can just edit some code in a text editor and compile it. Still, since this is perfectly possible in a batch file I'd also say C# is overkill.
–
JoeyMar 16 '09 at 13:16