Avoid sharing the parent process's stdin handle to python on Windows + other Windows bat script fixes

[juj]

This PR performs the following fixes:

1. Add an env. var EM_WORKAROUND_PYTHON_BUG_34780 that enables avoiding sharing the parent process's stdin handle to python when invoking python via emcc.bat script, to prevent a rare python deadlock hang bug https://bugs.python.org/issue34780
2. Add an env. var EM_WORKAROUND_WIN7_BAD_ERRORLEVEL_BUG that enables explicitly exiting the batch script with python errorlevel code, to work around a Windows 7 bad batch script exit code issue. We have not found a description of this bug on the web, but the issue that occurs is that on Windows 7, the invoked batch scripts return with a nonzero exit code, even if the python subprocess call was clean with exit code zero and the %ERRORLEVEL% variable in the batch script itself was zero. This is possibly caused by the same python bug 34780 as above, but we have no confirmation about this. Therefore it is important to treat this separately because the "nuclear option" of exit %ERRORLEVEL% will exit the parent shell as well.
3. Fix batch scripts to not leak env. vars to parent shell by adding a setlocal directive.
4. Fix a peculiar Windows batch script parsing issue where if a :: comment line is placed inside a if () block, it will be somehow parsed by the interpreter. E.g. if one would have a bat script

@if ""=="" (
:: If _EMCC_CCACHE is not defined below, do a regular invocation of em++.py compiler.
:: Python Windows bug https://bugs.python.org/issue34780: If emcc.bat was invoked via a
:: shared stdin handle from the parent process, and that parent process stdin handle is in
:: a certain state, running python.exe might hang here. To work around this, invoke python
:: with '< NUL' stdin to avoid sharing the parent's stdin handle to it, avoiding the hang.
  echo hello
)

then running this bat script will print

C:\code>test.bat
The system cannot find the drive specified.
The system cannot find the drive specified.
hello

These two error prints come from Windows bat script interpreter somehow parsing the comment strings as path names.

However, the following bat script

:: If _EMCC_CCACHE is not defined below, do a regular invocation of em++.py compiler.
:: Python Windows bug https://bugs.python.org/issue34780: If emcc.bat was invoked via a
:: shared stdin handle from the parent process, and that parent process stdin handle is in
:: a certain state, running python.exe might hang here. To work around this, invoke python
:: with '< NUL' stdin to avoid sharing the parent's stdin handle to it, avoiding the hang.
@if ""=="" (
  echo hello
)

correctly prints out

C:\code>test.bat
hello

so Windows parses comments somehow differently inside if () sections. This means that we should avoid placing :: comments inside if () sections in these batch scripts.

[kripken]

This seems necessary, but it does mean we can't do emcc.bat < file.cpp I assume? If so, documenting that at least might be a good idea.

[sbc100]

This seems necessary, but it does mean we can't do emcc.bat < file.cpp I assume? If so, documenting that at least might be a good idea.

I thou would need to add - to make that work.. but yes it would be shame too loose that compatibility. Today I can do:

echo "int foo;" | gcc -x c -c -
echo "int foo;" | clang -x c -c -
echo "int foo;" | emcc -x c -c -

On the other hand as long as this only effects windows I think they usage of stdin is probably less there ..

[juj]

Updated this PR to contain all the different changes to the batch scripts altogether. Realizing that not everyone will be affected by the Python issue, I opted to gate these workarounds behind env. vars so that people who are not affected will not lose out on features.

[sbc100]

Without the /b does this not exit the entire cmd.exe shell?

[juj]

That's right, though unfortunately with the /b flag that will not fix the Windows 7 issue. The /b flag is used in the other part to avoid a goto, which would reset the %errorlevel% variable to zero.

[sbc100]

So users of EM_WORKAROUND_WIN7_BAD_ERRORLEVEL_BUG are opting into not being able to use these tools in a command shell, is that the idea? Maybe it would never make sense there?

[sbc100]

(Sorry I should have read all of your above comments.. I see it mentions this there).

[juj]

Yeah, that is the case - when one enables EM_WORKAROUND_WIN7_BAD_ERRORLEVEL_BUG, that will cause the shell to quit. For command line uses that would be quite undesirable, hence placing it under a separate workaround env. var.

[sbc100]

I the old version of this script we don't call exit at all.. but somehow the exit code is still set correctly? (I guess because the emcc command is the very last one?).

I wonder if it possible for the ":NORMAL" case to continue to work that way.. if we place it last in the script can we avoid calling exit at all maybe?

:NORMAL
@%CMD% %*

That way maybe EM_WORKAROUND_WIN7_BAD_ERRORLEVEL_BUG will only be needed if EM_WORKAROUND_PYTHON_BUG_34780 is also used?

[sbc100]

Also maybe we would not longer need NORMAL_EXIT at all in that case?

[juj]

I wonder if it possible for the ":NORMAL" case to continue to work that way.. if we place it last in the script can we avoid calling exit at all maybe?

That is a very good suggestion. Updated to that form.

Also maybe we would not longer need NORMAL_EXIT at all in that case?

We do need that case, if we want to orthogonally support all combinations of EM_WORKAROUND_WIN7_BAD_ERRORLEVEL_BUG and EM_WORKAROUND_PYTHON_BUG_34780. I don't think it is a too bad thing to have the whole matrix (probably more consistent to have so, rather than oddly omit one of them)

[juj]

I the old version of this script we don't call exit at all.. but somehow the exit code is still set correctly? (I guess because the emcc command is the very last one?).

Yes, normally %ERRORLEVEL% is received from the last command in the file. However on Windows 7 we observe that even if %ERRORLEVEL% is zero in the bat script right after a call to python emcc.py, the bat script still incorrectly exits with ERRORLEVEL=1. Explicitly quitting with exit %ERRORLEVEL% works around that.

[sbc100]

I the old version of this script we don't call exit at all.. but somehow the exit code is still set correctly? (I guess because the emcc command is the very last one?).

Yes, normally %ERRORLEVEL% is received from the last command in the file. However on Windows 7 we observe that even if %ERRORLEVEL% is zero in the bat script right after a call to python emcc.py, the bat script still incorrectly exits with ERRORLEVEL=1. Explicitly quitting with exit %ERRORLEVEL% works around that.

Oh I see.. so that issue already exists today and is completely separate to the other one. Make sense.

[sbc100]

I the old version of this script we don't call exit at all.. but somehow the exit code is still set correctly? (I guess because the emcc command is the very last one?).

Yes, normally %ERRORLEVEL% is received from the last command in the file. However on Windows 7 we observe that even if %ERRORLEVEL% is zero in the bat script right after a call to python emcc.py, the bat script still incorrectly exits with ERRORLEVEL=1. Explicitly quitting with exit %ERRORLEVEL% works around that.

Oh I see.. so that issue already exists today and is completely separate to the other one. Make sense.

Does that mean that emcc.bat on windows 7 always returns success today? If windows 7 is so badly broken (and has been like that forever) how are not hearing more about this?

[juj]

Does that mean that emcc.bat on windows 7 always returns success today?

No. We are seeing on Windows 7 when we spawn emcc.bat via tundra.exe, it will cause emcc.bat to always return exit code 1 (failed) back to tundra subprocess exit code. When emcc.bat is launched from cmdline as usual on Win 7, it does return 0 as usual. On Win8 and newer, this does not occur.