Windows command interpreter: how to obtain exit code of first piped command

In the example provided below, I execute nmake and then redirect STDOUT/STDERR to tee, which then sends it to the screen, and also to a log file. The problem is that I'm trying to capture the exit code for nmake and not tee. What I need is the exit code from nmake, and not tee.

nmake | tee output.txt

Solution 1:

You might think you could do something like the following, but it won't work.

(nmake & call set myError=%%errorlevel%%) | tee output.txt

The problem lies in the mechanism by which Windows pipes work. Each side of the pipe is executed in it's own CMD shell. So any environment variable you set there will disappear once the command has finished. Also the delayed expansion of %errorlevel% is more complicated because of the extra level of parsing, and because the CMD shell has a command line context instead of a batch context.

You could do something like this:

(nmake & call echo %%^^errorlevel%% ^>myError.txt) | tee output.txt
for /f %%A in (myError.txt) do echo nmake returned %%A
del myError.txt

Or you could embed the errorlevel in your output.txt:

(nmake & call echo nmakeReturnCode: %%^^errorlevel%%) | tee output.txt
for /f "tokens=2" %%A in ('findstr /b "nmakeReturnCode:" output.txt') do echo nmake returned %%A

Both solutions above assume you are running the commands in a batch script. If you are executing the commands from the command line instead, then both solutions above need
%^^errorlevel% instead of %%^^errorlevel%%.

But given that nmake does not require user input, and it is usually fast so real time monitoring is probably not an issue, then the simplest solution seems to be

nmake >output.txt
set myError=%errorlevel%
type output.txt
echo nmake returned %myError%

Note - there are many subtle complications when working with Windows pipes. A good reference is Why does delayed expansion fail when inside a piped block of code?. I recommend reading the question and all the answers. The selected answer has the best info, but the other answers help provide context.

EDIT 2015-06-02

I've recently discovered you can use DOSKEY macros to cleanly store and retrieve the ERRORLEVEL from either (or both) sides of a pipe, without resorting to a temporary file. I got the idea from DosTips user Ed Dyreen at http://www.dostips.com/forum/viewtopic.php?p=41409#p41409. DOSKEY macros cannot be executed via batch, but the definitions persist after ENDLOCAL and CMD /C exit!

Here is how you would use it in your situation:

(nmake & call doskey /exename=err err=%%^^errorlevel%%) | tee output.txt
for /f "tokens=2 delims==" %%A in ('doskey /m:err') do echo nmake returned %%A

If you want, you can add one more command at the end to clear the definition of the err "macro" after you have retrieved the value.

doskey /exename=err err=

Solution 2:

There is a version of "tee" (called mtee => https://ritchielawrence.github.io/mtee/) that optionally adopts the exit code of the piped process. With that you could write

nmake | mtee /E output.txt

Solution 3:

Inspired by the answer of @dbenham, I made the following version:

(%cmd% & call echo EXIT /B %^^ERRORLEVEL% >%ret_file%)
      | tee %log_file% & %ret_file%>NUL

It is a one-liner, that can be used on the command line, or in a batch file. It has the advantage that the line ends up producing the correct %ERRORLEVEL%, so you can evaluate it in the traditional way.

1. The command %cmd% gets executed, setting %ERRORLEVEL% to the value we need to retrieve.
2. We'using the CALL mechanism to get manual delayed expansion (so we get the correct value of %ERRORLEVEL%). The call creates a mini-command as a batch file %ret_file%) that exits with the same %ERRORLEVEL% as the original command %cmd%.
3. The pipe does whatever it needs to do, followed by the execution of the mini-command %ret_file%, setting the %ERRORLEVEL% to the appropriate value.

The disadvantage is that the one-liner litters your directories with little files containing

EXIT /B <some_error_value>

You can easily adjust the one-liner so the script %ret_file% becomes self-erasing upon execution.