CODEWITHSUNDEEP
windowsbatch-filecmd
s1m0n
s1m0n

Reputation: 41

Why does console output keep self-referencing batch script from exiting cleanly?

I was writing a self-referencing Windows 10 (home ed.) batch script to locate a string in a large number of log files, create a results file and, when finished, open the log file in notepad++. This process sometimes takes a few minutes hence the self-referencing part which allows me to return control to the original command window until the log file is opened (and takes focus).

However, when the second command window, started with the "start" command and the "/b" switch, includes at least one "echo" command it won't exit cleanly and requires me to press the Enter key to fully exit that "nested" command window.

I've distilled the code down to nine lines so you can hopefully see what I mean. To see it in action, save the following as "test.bat" and run it from a command prompt:

@echo off
if "%1" EQU "" call :noArgs & goto :done
echo There was at least one argument.
:done
exit /b
:noArgs
echo There were no arguments.
start "" /b cmd /c test.bat arg1
goto :eof

It will print "There were no arguments." below the prompt followed by "There was at least one argument." at the prompt and then hang, waiting for the Enter key before returning control back to the prompt.

If you remove the line:

echo There was at least one argument.

the Enter key is no longer needed for the second command shell to exit. Similarly, if the output from the echo command is redirected to a file the issue goes away. This problem also occurs without echo commands but if output is generated from EG the type command so it seems it is due to there being some form of console output. This can be easily demonstrated by commenting out both the "echo" line as well as the first line "@echo off" - with commands now being echoed to the console it again hangs before exiting.

I could get around this issue by changing the "start" call to this:

start "" /min cmd /c test.bat arg1

however any output is no longer easily visible in the minimized window so it's a poor solution.

I'd love to know why the code I posted behaves the way it does, why it won't exit cleanly without requiring the Enter key to be pressed. The only clue I have is from the "remarks" column in the matrix on this page Close and exit batch files that states, "Make sure no text is displayed in the console window to make it close automatically at the end of the batch file". However that seems to refer only to Windows 9.x versions of command.com - not EG Windows 10 nor cmd.exe.

Thanks for any input/thoughts.

-s1m0n-

Upvotes: 3

Views: 336

Answers (1)

Harry Johnston
Harry Johnston

Reputation: 36318

You're misinterpreting the output. If I've understood you rightly, it looks like this:

C:\working\test>test
There were no arguments.

C:\working\test>There was at least one argument.

That happened like this:

C:\working\test>                                    <---- output from first shell
                test                                <---- input
There were no arguments.                            <---- output from first shell
                                                    <---- output from first shell
C:\working\test>                                    <---- output from first shell
                There was at least one argument.    <---- output from second shell
                                                    <---- cursor is here

The second shell is running asynchronously - that's what start does - so the first shell has already finished the batch job and printed the next prompt by the time the second shell gets around to printing its output.

At this point, the second shell has exited, and the first shell is waiting for you to enter a command. It doesn't know that the second shell has printed anything, so it has no reason to think that it needs to reprint the prompt. But if you enter a command, it will work.

Upvotes: 4

Related Questions