I first discovered this illogical behavior nearly 5 years ago at File redirection in Windows and %errorlevel%. Two months later I discovered the same issue with the RD (RMDIR) command at batch: Exit code for "rd" is 0 on error as well. The title of that last question is actually misleading, because the return code of a failed RD is non-zero, but the ERRORLEVEL is unchanged from whatever value existed before the command was executed. If the return code were truly 0, then the || operator would not fire.
Is all this only possible with (failed) redirections, because such are
handled before any commands are executed?
You are correct that the redirection fails before the command is executed. And the || is responding to the non-zero return code of the redirection operation. The command (ECHO in your case) is never executed if the redirection fails.
So what is the connection between the ErrorLevel value and the ||
operator, why is ErrorLevel affected by ||? Is || copying the exit
code to ErrorLevel?
There are two different error related values that must be tracked - 1) any given command (or operation) return code (exit code), and 2) ERRORLEVEL. Return codes are transient - they must be checked after every single operation. ERRORLEVEL is the cmd.exe way to persist the "important" error states over time. The intent is for all errors to be detected, and the ERRORLEVEL is to be set accordingly. But ERRORLEVEL would be kind of useless to batch developers if it were always cleared to 0 after every successful operation. So the designers of cmd.exe attempted to make logical choices as to when a successful command clears the ERRORLEVEL, and when it preserves the prior value. I'm not sure how wise they were in their choices, but I have attempted to document the rules at Which cmd.exe internal commands clear the ERRORLEVEL to 0 upon success?.
The rest of this section is educated conjecture. I don't think a definitive answer is possible without communication from the original developers of cmd.exe. But this is what gives me a mental framework to successfully navigate the morass of cmd.exe error behavior.
I believe that wherever an error can occur within cmd.exe, the developers were supposed to detect the return code, set the ERRORLEVEL to non-zero upon error, and then fire any || code if it is in play. But in a few cases the developer introduced a bug by not playing by the rules. After failed redirection or failed RD, the developer(s) successfully invoked the || code, but failed to set the ERRORLEVEL properly.
I also believe that the developer(s) of || did some defensive programming. The ERRORLEVEL should already be set to non-zero before || code is executed. But I think the || developer wisely did not trust his/her peers, and decided to set the ERRORLEVEL within the || handler as well.
As to what non-zero value is used, it seems logical that || would forward the original return code value to ERRORLEVEL. This would mean that the original return code must have been stored in some temporary storage area that is distinct from ERRORLEVEL. I have two pieces of evidence that support this theory:
1) The || operator sets at least 4 different ERRORLEVEL values when RD fails, depending on the type of error.
2) The ERRORLEVEL set by || is the same value that CMD /C sets, and CMD /C simply forwards the return code of the last command/operation.
C:est>(call )&rd .
The process cannot access the file because it is being used by another process.
C:est>echo %errorlevel%
0
C:est>(call )&rd . || rem
The process cannot access the file because it is being used by another process.
C:est>echo %errorlevel%
32
C:est>(call )&cmd /c rd .
The process cannot access the file because it is being used by another process.
C:est>echo %errorlevel%
32
However, there is one peculiarity that threatens to invalidate this theory. If you attempt to run a non-existent command, then you get a 9009 error:
C:est>invalidCommand
'invalidCommand' is not recognized as an internal or external command,
operable program or batch file.
C:est>echo %errorlevel%
9009
But if you use the || operator, or CMD /C, then the ERRORLEVEL is 1 :-/
C:est>invalidCommand || rem
'invalidCommand' is not recognized as an internal or external command,
operable program or batch file.
C:est>echo %errorlevel%
1
C:est>(call )
C:est>cmd /c invalidCommand
'invalidCommand' is not recognized as an internal or external command,
operable program or batch file.
C:est>echo %errorlevel%
1
I resolve this anomaly in my mind by assuming that the code responsible for setting the 9009 ERRORLEVEL in the absense of || must be doing some type of context sensitive translation to generate 9009. But the || handler is not aware of the translation, so it simply forwards the native return code to ERRORLEVEL, overwriting the 9009 value that is already there.
I am not aware of any other commands that give different non-zero ERRORLEVEL values depending on whether || was used or not.
Even more strangely, I could not observe the opposite behaviour --
ErrorLevel being reset to 0 by && --, when correctly reverting the
test setup (that is, replacing (call ) by (call) (to set ErrorLevel to
1 initially), clearing the read-only attribute of file test.tmp,
creating file test.nil (first line not empty to avoid set /P to set
ErrorLevel to 1), and using file extension .bat rather than .cmd for
testing (to avoid set /P to reset ErrorLevel to 0)).
Once you accept that not all commands clear the ERRORLEVEL upon success, then this behavior makes perfect sense. It wouldn't do much good to preserve prior errors if the && were to wipe out the preserved error.
