Add a comment to the x.py shebang, using /usr/bin/env

[jyn514]

This is a terrible, horrible, no-good, very-bad idea.

I kind of like it.

---

Shebang files can't have comments, so instead this passes --unset VAR, where the variable name itself is the comment.
Here's an example run of py on Windows:

PS C:\Users\Joshua Nelson\src\rust> py x.py
Unable to create process using '/usr/bin/env -S -u If_this_file_fails_to_run,read_README_ENTRYPOINT.md bash ./x.py'

This doesn't break anyone using python/python2/python3 directly, and still handles trying all three on distros where they might not exist. Unfortunately it's slightly less portable since not all env commands support -S and -u.

---

Happy to take improvements on the file name - I'm slightly reluctant to use spaces or punctuation since lots of shell scripts are bad at handling those, but since nothing should be invoking this file directly other than the kernel, it's probably fine.

Helps with #98650.

r? @Mark-Simulacrum cc @dtolnay @CAD97 @yoshuawuyts

[Mark-Simulacrum]

I feel like it might be simpler (and more instructive) to name the file something like "please_read_this_file.sh", and embed actual suggestions into the file.

My sense was that the auto-discovery mechanism planned(?) or already implemented for the Windows py tooling will look in the Windows equivalent of /usr/bin for the file here -- will that work with a current-directory relative path? Will that work when invoking x.py from a different working directory (e.g., ../x.py), including on linux/macos? (In other words, is the relative path relative to the file being executed?)

[dtolnay]

Will that work when invoking x.py from a different working directory (e.g., ../x.py), including on linux/macos? (In other words, is the relative path relative to the file being executed?)

Linux:

$ ../x.py
/bin/sh: 0: cannot open ./src/bootstrap/if_this_file_fails_to_run_try_using_python3_x.py_instead.sh: No such file

[CAD97]

The auto-discovery behavior of py.exe will take the shebang, remove a prefix of /usr/bin/env , /usr/bin/, or /usr/local/bin/, and then search in PATH for an executable with that name an an extension in PATHEXT¹. Using a /bin/sh means that py will search for a file called /bin/sh with an autorun extension.

The goal in this PR is to use a shebang which is meaningful to POSIXy shells but will consistently fail and show a kinda-useful error message when run under py.exe.

I'm slightly reluctant to use spaces [...], but since nothing should be invoking this file directly other than the kernel, it's probably fine.

It at least looks like for MINGW, the first space (after a non-space) is split to get the program and a singular argument string. To recover split arguments you need to use env -S.

Will that work when invoking x.py from a different working directory (e.g., ../x.py), including on linux/macos?

In MINGW, a relative path in the shebang is relative to cwd, not the file being interpreted.

Footnotes

1. The unmodified value is .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC. ↩

[CAD97]

Independently: if this technique can be made to work, it's probably better to recommend python x.py (or just a name README.sh) instead of python3 x.py; the filename should only ever show up on Windows which IIUC distinguishes pythons via path and not via executable name.

[jyn514]

I pushed a modified version of this that respects the current directory. Unfortunately it's a little less portable because it requires env to support both -S and -u - not sure that exists on all distros.

[m-ou-se]

Unfortunately it's a little less portable because it requires env to support both -S and -u - not sure that exists on all distros.

-S is not Posix. It seems supported by env on macOS, and by GNU coreutils' env. But at least busybox does not support it.

[Ella-0]

toybox doesn't support env -S either

[bjorn3]

Maybe add a year to this in case someone forgets to update this and it remains in place next year?

[jyn514]

Unfortunately it's a little less portable because it requires env to support both -S and -u - not sure that exists on all distros.

-S is not Posix. It seems supported by env on macOS, and by GNU coreutils' env. But at least busybox does not support it.