[Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

Paul Moore p.f.moore at gmail.com
Mon May 6 22:30:02 CEST 2013

On 6 May 2013 20:46, Steve Dower <Steve.Dower at microsoft.com> wrote:

> To summarise the bug, when PowerShell invokes a command based on an
> extension in PATHEXT, only the first three characters of the extension are
> used to determine the associated program. I tested this by creating a file
> "test.txta" and adding ".TXTA" to my PATHEXT variable. Typing ".\test" in
> PowerShell opened the file in my text editor. This only affects PowerShell
> (cmd.exe handles it correctly) and only in the case where you don't specify
> the extension (".\test.txta"  works fine, and with tab completion, this is
> probably more likely). It also ignores the associated command line and only
> uses the executable.

The form in which I hit the bug is that I tried to create a "script"
extension so that "foo.script" would be a generic script with a #!
extension specifying the interpreter. I was adding the extension to PATHEXT
so that scripts would be run "inline" (displaying the output at the console
prompt, rather than in a new transient console window) - again this is a
Powershell-specific issue which does not affect CMD.

But when I added .script to PATHEXT, the script ran, but in a separate
console window, which flashed up too fast for me to see the output. (It may
be that it's the clash with .scr screensaver files that caused the file to
be treated as a windows executable rather than a console executable, but
it's hard to tell when you can't see the error message :-()

> (I'll pass this on to the PowerShell team, though I have no idea how
> they'll prioritise it, and of course there's probably no fix for existing
> versions.)

Thanks. In my view, it's a vaguely irritating rough edge rather than a
dealbreaker. But it does cause problems as here. And the number of rough
edges in powershell when dealing with "traditional" console commands (e.g.,
see the point above about needing PATHEXT to get inline output, rather than
just to be able to omit the extension) are sufficient to make the
accumulation greater than the sum of its individual parts.

> Because we'd be claiming both .pyz and .pyzw, it's possible to work around
> this issue if we accept that .pyzw files may run with the .pyz program
> instead of the .pyzw program. Maybe it goes to something other than py.exe
> that could choose based on the extension. (Since other command-line
> arguments get stripped, adding an option to py.exe can't be done, and
> unless the current behaviour is for it to open .pyw files in pythonw.exe, I
> wouldn't want it to be different for .pyzw files.)

I'm not sure the behaviour is clearly defined enough to be certain of this
(although I'll defer to someone who's looked at the Powershell source code
:-)). In my experiments, it was frustratingly difficult to pin down the
exact behaviour with any certainty. And given that the choice is over
running a console executable or a Windows one, it can be particularly bad
if the wrong one is run (console program pops up in a transient second
window and the output gets lost, for example). Add the fact that the
powershell behaviour is essentially undocumented, and it's hard to
guarantee anything.

On the plus side, I suspect (but haven't proved) that if the GUI extension
(pyzw) gets misread as the console one (pyz) the behaviour is less serious,
because PATHEXT is not as relevant for GUI programs.

> However, anywhere in Windows that uses ShellExecute rather than
> FindExecutable will handle long extensions without any issue. AFAIK, this
> is everywhere except PowerShell, so I don't really see a strong case for
> breaking the w-suffix convention here.

To be blunt, I see no point in using a pair of extensions that are known to
be broken, even if only in Powershell, over a pair that will work
everywhere (but are no more than mildly less consistent with other cases -
note that while there's a py/pyw pair, there is no pycw corresponding to
pyc, or pyow corresponding to pyo).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130506/27b6ed55/attachment-0001.html>

More information about the Python-Dev mailing list