Order and position of cmd.exe redirection operators
First about order
Below are the redirects to stdout
and strerr
to nul
.
command 1>nul 2>&1
Below <
command 2>&1 1>nul
Why does order matter? How can this expression be read in human-readable language?
About position
It works
command 1>nul 2>&1
and this too
1>nul 2>&1 command
Why? Any official reference documentation on syntax rules would be helpful.
source to share
command 2>&1 1>nul
does not work correctly. It works. But as usual, it does what you asked not what you wanted
From left to right:
-
2>&1
the data on stream 2 (stderr) will be sent to a copy / duplicate of the descriptor that stream 1 (stdout) uses. -
1>nul
data in stream 1 will be sent tonul
.
The duplicate is the key. Data is not sent to any stream, but rather to a copy of the stream descriptor. When stream 1 is redirected, stream 2 has its own descriptor, a copy of the previous stream 1. Changing stream 1 does not affect stream 2
Now let's see the working code from left to right
-
1>nul
Set handle on stream 1 to point to nul -
2>&1
Set the descriptor on stream 2 to a copy of the descriptor used on stream 1, i.e. the descriptornul
About position
In most cases, the position (before the command, after the command, or with both) does not matter. To execute a command, the parser must first prepare the streams that the command will use. This preparation is done if deemed necessary (try redirecting the command I / O rem
) before starting the command.
The only cases where there is a difference are what we want from the command and what the parser understands. One obvious case is when we need to output a string with a trailing digit. Code like
echo 1 2 3>file
will not send the complete line to the target file. 1 2
will be displayed on the console and the data written to stream 3 (nothing in this command) will be sent tofile
Of course, you can add a space (between 3
and >
) at the end of the data , but that space will be included in the output. If this is not acceptable, the solution is to move the redirect at the beginning of the command
>file echo 1 2 3
source to share
CMD
just emulates command.com
from MSDOS 5
. Additional added features have been applied as a "wrapper", encapsulating existing functionality and quirks to ensure that existing batches have the least impact.
There are many unclear decisions of the developer (s). It looks like a low priority project is poorly controlled, as evidenced by poor and inconsistent spellings in the inline documentation, the decision to have a null-valued string be interpreted as octal rather than decimal instead of using O'123'
similar H'123'
to hex. No switch /u
for universal date format in datetime utilities and dozens of other quirks requiring workarounds - all of which point to a poorly supervised project left to a cavalry developer not embraced by the realities of commercial programming.
So - syntax 2&1
is an add-on poorly applied to a product that he hoped would disappear under pressure from the point-to-click-and-giggle generation. Hence, it is not "industrial strength", but ironically preserved for all this.
The fact that little has evolved over the past decade or more shows the status of a "bad cousin". There is no money because it is not flashy and, while backward compatible, it ties in with a mindset ultimately rooted in the 1950s.
Hence, there is no commercial reason for the anomalies introduced by post-DOS5 enhancements that need to be addressed. The problem of consistency arose out of the mindset of the programmer, not assuming that someone would try to use new tools in any other way that seemed logical to that particular programmer.
Hence, you are using redirection as this programmer decided and don't expect that to change anytime soon - unless you come up with a few million to fund the development of what you want, I Expect.
source to share