.bat does not always pass parameter correctly at EOF (end-of-file)

[MtheK]

I discovered a weird problem that currently occurs on Win7 and Win10.
If the last line of a .bat calls another .bat, setting STDOUT to null,
and passing a parameter (last in the command line), and that last line
does NOT end with a CRLF (0D0Ah), then the parameter is NOT passed,
causing problems if the called .bat expects one.

For example, put these 2 .bats in a WDIR, 'cd' to it in a DOS prompt,
and run the first .bat, noticing the output:

testbat1.bat:

Code: Select all

::   note that this line DOES have the "invisible" (via NOTEPAD) CRLF...
call testbat2.bat >nul b0
::   ensure that this line does NOT(!!!) have the CRLF at the end...
call testbat2.bat >nul b0

testbat2.bat:

Code: Select all

set TESTBATparm=
set TESTBATparm=%1
set TESTBATparm

output:

Code: Select all

C:\WDIR>testbat1.bat
C:\WDIR>call testbat2.bat  b0 1>nul
C:\WDIR>call testbat2.bat  1>nul
Environment variable TESTBATparm not defined

Does anyone else have this problem? Is this just a restriction?
It took me all morning to find the circumvention (ie: ensure the
last line of testbat1.bat ends with a CRLF).
It seems that the preceding >nul actually causes this problem in
combination with the missing CRLF.

Thankx...

[pieh-ejdsch]

It's actually related to the redirect.
If the redirect sneaks into the command out of place, then the first token after the redirection is missing a whitespace character.
If there are more than two tokens behind the redirection, the command line is executed in full.
It is best to put the redirect at the beginning of the command line or before the command.

Phil

[MtheK]

Very cool...thank you!