Powershell: Add correct hashbang executon and handling for various languages

[eabase]

Back in the beginning of time there was an issue dealing with the way powershell handles (executable) script files, most often seen in anything made in a native *nix environment. The idea is to be able to run hashbanged scripts from pwsh.

Q: What is a hashbanged script?
A: Pretty much any script starting with something like:

#!/usr/bin/env python3
# mypyscript -- This is any random python coded script executable from command line
print('Don't let hashbang issues disappear like teardrops in the sea!')
...

_{Yes, so you noticed this hashbang is not for windows. Well, yes a no. It is correct for WSL, but powershell doesn't understand it for the obvious reason, it is supposed to be path. However, if Windows powershell would like to maintain any compatibility with any future script handling, pwsh developers need to rethink this "path": /usr/bin/env and handle it as a virtual path like any of the other special windows paths.}

Two things for sure.

1. It should not, under any circumstances, change what's in the original code.
2. Windows/Powershll dev's should not start putting their own Windows paths there.
   (Instead consider removing the path altogether, by using just the interpreter's name, like #!python3, but maintaining full compatibility with the 20+ year /usr/bin/env and /bin/<interpreter> formats.

Steps to reproduce

./mypyscript

# doesn't work

Expected behavior

./mypyscript

Don't let hashbang issues disappear like teardrops in the sea!

We should be able to dot-execute any scripted code from powershell command line, when that code contain the correct hashbang for the scripting engine. (Eg. .ps1 .py .go .js etc.)

Actual behavior

• Doesn't work:
  Opens a window dialog, asking what you want to use to open this file.

• A secondary issue, is that:
  some installers actually modify the original code's first hashbang line.
  This should never be allowed to happen!

---

A longer and far more technical and detailed discussion of this, was made in this issue:

• https://github.com/PowerShell/PowerShell/issues/9430

But it's title is perhaps not ideal, to make it a very relevant issue, although it is the essence.
(Issue pertains to handling of . (dot) in the $env:PATHEXT. )

Furthermore there was an honest attempt by @mklement0 to provide a CMD-based work-around
as discussed in this SO question:

• https://stackoverflow.com/questions/55601446/how-to-run-a-python-program-from-powershell-based-on-python-hashbang

[jborean93]

IIRC shebangs/hashbangs are really handled in the kernel and not the shell and the Win32 subsystem on the NT kernel doesn't have a concept of shebangs. For non-executable files, Windows really uses the extension of the file to determine what program to use to open the file itself so when you do ./mypyscript with a shebang of #!/usr/bin/env python3 Windows has no idea what to do with it. Even trying to add support for interpreting Unix shebangs will be fraught with danger and IMO too magical, using #!/usr/bin/env python3 as an example:

• On Windows Python is just installed with python.exe so there will be no python3.exe in the PATH
• Even if there was, what Python 3 interpreter will be used if there are multiple present
• If it was also just #!/usr/bin/python3 then it's the same issue, probably even more so because it's a hardcoded path and on Unix it won't rely on the PATH

Personally I think this would require too much magic and maintenance to achieve.