DosTips.com

Why does NUL capture the text I intend for TIME.TXT ?
I only seem to get the result I want if I use parenthesis, i.e.


I wasted an hour or two before I tried the parenthesis, and I would like to FULLY understand :-
Why I need the parenthesis ;
Any convenient alternatives ;
Any further "gotchas" that I might stumble across

Reason I stumbled into this problem :-
I was echoing a messages to create various single line files in the current directory.
When the file name was short then all was well.
When the file name was long then there was an error message that with typical Microsoft Stupidity stated :-
"The system cannot find the path specified."
CMD.EXE was STANDING on the path that it was using - it did not have to go and find it
So naturally I redirected the error message to NUL.
UNFORTUNATELY EVEN IF the file name was short and the file could have been created,
then the message intended for the file was redirected to NUL instead.

N.B. The purpose of the exercise was to start with a single folder on a long path about 250 characters long,
and build in that folder a series of files with name of increasing length until reaching the Windows limit of 260 characters including the terminating NUL.


Incidentally, I had forgotten the correct term for "brackets" so I looked up
http://www.dostips.com/DtCodeSnippets.p ... ndGrouping
Parentesis is the word I found above - which earns a red squiggle from my spelling checker, and Google takes me to foreign sites such as Spanish, and suggests
Parenthesis

Regards
Alan

Case 1:

The command processor (CP) executes this atomic expression:
At first it redirects the streams by handles, and then executes the command.

So if no error occurs the CP:
1. redirects the standard output stream (STDOUT) to a FileOutputStream (filename) (Wrong: See jebs next post.)
2. redirects STDOUT to the NUL device.
3 executes the command

So NUL is in this case the STDOUT of this program.


(This following will not happen on "echo %time% > filename > NUL": See jebs next post)
If the "> filename" doesn't success then the following happens:
1. redirects the standard output stream (STDOUT) to a FileOutputStream (Filename) fails
2. redirects STDOUT to the NUL device.
3 report error message to STDOUT, command is not executed

Nevertheless, on a single redirection to file step 2 and 3 would happen as described
You can verify it:


Case2:

The CP executes this as a complex expression:
At first it executes the the block with the redirection "(...) > NUL",
then the CP executes the commands within the block.

So if no error occurs the CP:
1. redirects STDOUT of the block to the NUL device.
2. executes the commands inside
3. redirects the standard output stream (STDOUT) to a FileOutputStream (filename)
4. executes the (echo) command

So FileOutputStream (filename) is in this case the STDOUT of this program.

If the "> filename" doesn't success then the following happens:
1. redirects STDOUT of the block to the NUL device.
2. executes the commands inside
3. redirects the standard output stream (STDOUT) to a FileOutputStream (filename) this failes
4. report error message to STDOUT, (echo) command is not executed


I have left out some details, but that's it.

penpen

Edit: Corrected/marked the errors.

Btw you can see what happens with the magic ECHO ON



And you will see that it's collapsed to


The parser only allows one redirection per handle, and the last one wins.
And all other redirections are removed without any checking against syntax nor file existance.

Then even this works

I thought, I have tested that,... but i only tricked myself out when verifying it:

But the content of the file was not from this run, so i have derived false information.
Sorry for that misinformation.

penpen

Thanks for the replies.

I wildly experimented to find some sort of work-around before I started this topic.
I am much happier that I have a viable solution now that I understand what is happening.

Regards
Alan

Very interesting. I remember from my C class that this would be some sort of order of operations and nesting, but didn't think that was possible in batch files. I'm sure I needed this a time or two before.