gh-99442: Fix handling in py.exe launcher when argv[0] does not include a file extension #99542
Conversation
zooba
commented
Nov 16, 2022
•
zooba
commented
- Issue: Python launcher invoked with command "py" fails to start process #99442
… include a file extension
| // the argument have no effect. A quoted argv0 must start and end | ||
| // with a double quote character; otherwise, it ends at the first | ||
| // ' ' or '\t'. |
There was a problem hiding this comment.
Technically speaking, any part of argv0 may be quoted. E.g. C:\"path to"\"py.exe" is parsed as C:\path to\py.exe by the crt. Being quoted just prevents tab or space from terminating the argument.
There was a problem hiding this comment.
Please see the associated bug (which I just fixed, because I put the wrong ID in the title originally).
We're following CreateProcess rules here, because it's going to be passed to CreateProcess.
There was a problem hiding this comment.
@ChrisDenton, The C runtime's more general parsing of argv[0] (i.e. multiple quoted parts terminated by space or tab) is only relevant if the executable path is passed explicitly to CreateProcessW() in lpApplicationName. If CreateProcessW() is called with lpApplicationName as NULL, as the launcher does, then the API parses the command to run from lpCommandLine. If the command line begins with a double quote, the API consumes all characters up to the next double quote or the end of the command line. If the command line doesn't begin with a double quote, the API tokenizes on space and tab characters, repeatedly searching until it finds a non-directory file.
For example, if the command line is r'C:\Program Files\Python311\python.exe', the API will execute "C:\Program.exe" if it exists. If the command line is r'"C:\Program Files\Python311\python.exe"spam', the API will execute "C:\Program Files\Python311\python.exe" if it exists. Note that there's an inconsistency with the C runtime's quoting rules. The CRT always splits arguments on an unquoted space or tab. For example:
>>> script = 'import sys; print(sys.orig_argv)'
>>> subprocess.call(fr'"{sys.executable}"spam -c "{script}"')
['C:\\Program Files\\Python311\\python.exespam', '-c', 'import sys; print(sys.orig_argv)']
0The API executed "python.exe", not "python.exespam".
There was a problem hiding this comment.
Yes, that inconsistency is what worried me. As far as I understand it, no normalization is being performed in the python code so the inconsistency remains? So the CRT and CreateProcessW will be understanding the arguments differently?
zooba
changed the title
|
Thanks @zooba for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11. |
… include a file extension (pythonGH-99542) (cherry picked from commit a220c6d) Co-authored-by: Steve Dower <[email protected]>
|
GH-99579 is a backport of this pull request to the 3.11 branch. |
