Work around Windows bug https://github.com/microsoft/terminal/issues/15212

[juj]

Work around Windows bug microsoft/terminal#15212 where %~dp0 expansion is broken, by attempting to look up emcc first in EMSCRIPTEN, and then in PATH if it cannot be expanded to via %~dp0.

Add a new test other.test_windows_batch_file_dp0_expansion_bug to check for this scenario.

[juj]

Fixes #19207

[sbc100]

The problem with this workaround is that it could end up running a different version of the tool.

For example, imagine I have \path\to\emscripten1 in the my PATH or in my EMSCRIPTEN environment variable, but then I run \path\to\emscripten2\emcc.bat explicitly on the command line. Perhaps this is not very comment but do it on linux during development quite a lot.

How common is this use case do you think? Could we instead simply error out with suggestions on how to fix?

Alternatively can we work towards dropping these .bat files completely and just using .ps1 instead? Or perhaps a tiny .exe or .com launcher program?

[juj]

The problem with this workaround is that it could end up running a different version of the tool.

True.

but then I run \path\to\emscripten2\emcc.bat explicitly on the command line. Perhaps this is not very comment but do it on linux during development quite a lot.

Calling \path\to\emscripten2\emcc.bat explicitly on the command line will not invoke the bug, and neither will calling \path\to\emscripten2\emcc.bat" cause it.

The bug only occurs if you call "emcc.bat" on command line, or if you create a bat script that calls "emcc.bat" with quotes, i.e. rely on PATH expansion to find emcc.bat.

error out with suggestions on how to fix?

Actually now that I think about this, I wonder why people would ever need to invoke "emcc.bat" with quotes from PATH, since emcc.bat will never have spaces in it.

Alternatively can we work towards dropping these .bat files completely and just using .ps1 instead?

I looked into this, but unfortunately at least .ps1 files are not possible, because they are not executable on Windows. I.e. calling "emcc" will not invoke "emcc.ps1", which is the very purpose of these bat scripts.

Or perhaps a tiny .exe or .com launcher program?

This might be possible.

[juj]

Actually, now sleeping on this, I realize that the only condition when this bug occurs is if one calls "emcc" (or "emcc.bat"), i.e. both
a) quotes are used to enclose the command, AND
b) shell lookup via PATH is relied on, i.e. emcc is not in the current working directory.

The bug does not occur if one calls "path\to\emcc" via a relative invocation, or "c:\path\to\emcc" via absolute invocation, even if quotes are used.

So it then stands to reason that if "%~dp0\emcc" does not locate the bat script, then looking up in PATH will repeat the same search as the calling shell did, and it will find the same emcc.bat file.

Changed this PR to remove the lookup to the EMSCRIPTEN environment variable. With this change the lookup is correct with no possibility of finding the wrong Emscripten.

[sbc100]

What is this for loop looping over?

[juj]

It is looping over an array of length 1, that has the string "%~n0.bat" as its only entry.

This is because the construct set MYDIR=%%~dp$PATH:I can only be invoked for a variable I that has been created as an iterator variable in a for statement.

[sbc100]

This line looks different to the other? Do you need to run ./tools/create_entry_points.py?

[juj]

This is due to a construct in tools\create_entry_points.py that does

# For some tools the entry point doesn't live alongside the python
# script.
entry_remap = {
  'emdump': 'tools/emdump',
  'emprofile': 'tools/emprofile',
  'emdwp': 'tools/emdwp',
  'emnm': 'tools/emnm',
}

...
      if entry_point in entry_remap:
        bat_data = bat_data.replace('%~n0', entry_remap[entry_point].replace('/', '\\'))

It is ok even if these look different. We could replace %~n0 in all scripts, not just the ones in tools/ , but that can be a separate improvement if so desired.