<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 6 May 2013 20:46, Steve Dower <span dir="ltr"><<a href="mailto:Steve.Dower@microsoft.com" target="_blank">Steve.Dower@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3d0">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.<br>
</div></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>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 :-()</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3d0">(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.)<br>
</div></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3d0">
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.)<br>
</div></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3d0">
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.</div>
</blockquote></div><br>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).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>Paul</div></div>