| Date: | May 18, 2006 / year-entry #171 |
| Tags: | tipssupport |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060518-07/?p=31153 |
| Comments: | 10 |
| Summary: | Although the redirection operator traditionally appears at the end of a command line, there is no requirement that it do so. All of these commands are equivalent: echo A B>C echo A>C B echo>C A B >C echo A B All of them echo "A B" to the file "C". You can use this trick... |
Although the redirection operator traditionally appears at the end of a command line, there is no requirement that it do so. All of these commands are equivalent: echo A B>C echo A>C B echo>C A B >C echo A B All of them echo "A B" to the file "C". You can use this trick to avoid the redirection problem we discussed last time. We saw that writing set message=Meet at 2 echo %message%>schedule inadvertently interprets the "2" as part of the redirection operator. One solution was to insert a space: echo %message% >schedule but this assumes that the space won't cause a problem. If you're in a case where that space will indeed cause a problem, you can use the trick above to move the redirection operator to a location where it won't cause any trouble: >schedule echo %message% |
Comments (10)
Comments are closed. |
And how far back does this work, NT(cmd.exe only)? 95/98? DOS?
IIRC, it worked that way back in the command.com from DOS 5 or so. Not sure about earlier.
(Of course in anything pre-cmd.exe, you can’t redirect stderr anyway, but putting a redirection at the beginning of the command did work. Actually in NT 4, you may not be able to redirect stderr either, but I’m not sure on that one.)
Anders: Feel free to report back with your findings.
Anders,
>dir.txt dir
works in Windows 95.
I think my brain just exploded.
Not really. This is pretty cool, but I can see how it would be used for evil (obfuscation).
The way it works is that the token immediately following a < or > is a filename for redirection, while everything else is part of the command to be executed. The parser has no reason to care where in the command the redirection token occurs.
I'm pretty sure that it just always worked this way, ever since redirection was first implemented. In fact, I suspect that this goes all the way to when the syntax was first created in Unix, around 1972.
Don't forget that Microsoft did the port of Unix to microcomputers shortly before DOS was released, so there would have been plenty of people around with Unix experience.
I think quoting is inevitable at some point.
Consider what happens if %message% contains a >
My head a splode.
However these command produce different results:
>dirsort.txt dir /b | sort /r
and
dir /b | sort /r > dirsort.txt
Well, um, yes, because in the first the redirection to dirsort.txt is part of the "dir" command. In the second, it’s part of the "sort" command.
So in the first, you’ve told the shell that stdout for the dir command should go to two different places (the file dirsort.txt and a pipe to another process). If you don’t get an error, the shell probably does either the first or last, but it won’t do both.