Thanks! I couldn't figure out how to make system stop waiting for the script to finish, but start /b seems to do the trick! One question -- I understand 1>nul, but what does the 2>&1 do? | [reply]
[d/l]
[select] |
For most POSIX-wannabe platforms, STDIN is handle 0, STDOUT is handle 1, STDERR is handle 2.
- "command >foo" is the same as "command 1>foo".
- "command 2>foo" redirects errors, not output.
- "command 2>&1" ties error output to wherever plain output is going.
Some command shells have different syntax for these, and some are picky about the order ("command foo 2>&1 1>foo" may act differently).
--
[ e d @ h a l l e y . c c ]
| [reply] |
2>&1 just says "redirect handle 2 (STDERR by convention) to the same place as handle 1 (STDOUT).
If it was preceded by 1>my.log, then output from both handles would end up in same file. In the case of redirection to nul, this is effectively the same as doing 1>nul 2>nul, but if you tried to do 1>my.log 2>my.log you will get
The process cannot access the file because
it is being used by another process.
under win32. When the file is opened for the first handle, it is opened for exclusive access, so when the the attempt is made to open it for the second handle you get this error.
Order is also important. If you try 2>&1 1>nul, then you are asking for handle 2 to be redirected to the same the as handle 1, which is the terminal by default (and the same place as the default for handle 2), you then redirect handle 1 to the nul device, but this does not also redirect handle 2, so output to STDERR wil still end up on the terminal and only the output to STDOUT will get bit-bucketed.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
| [reply]
[d/l]
[select] |