A python-help poster finally convinced me that there was a way to enable automatic wildcard expansion on win32. This is done by linking in "setargv.obj" along with all of the other MS libs. Quick testing shows that it works. Is this a feature we want to add? I can see both sides of that coin. --david PS: I saw a RISKS digest posting last week which had a horror story about wildcard expansion on some flavor of Windows. The person had two files with long filenames: verylongfile1.txt and verylongfile2.txt But Win32 stored them in 8.3 format, so they were stored as verylo~2.txt and verylo~1.txt (Yes, the 1 and 2 were swapped!). So when he did del *1.txt he removed the wrong file. Neat, eh? (This is actually relevant -- it's possible that setargv.obj and glob.glob could give different answers). --david
A python-help poster finally convinced me that there was a way to enable automatic wildcard expansion on win32. This is done by linking in "setargv.obj" along with all of the other MS libs. Quick testing shows that it works.
Is this a feature we want to add? I can see both sides of that coin.
I don't see big drawbacks except minor b/w compat problems. Should it be done for both python.exe and pythonw.exe? --Guido van Rossum (home page: http://www.python.org/~guido/)
A python-help poster finally convinced me that there was a way to enable automatic wildcard expansion on win32. This is done by linking in "setargv.obj" along with all of the other MS libs. Quick testing shows that it works.
This has existed since I have been using C on Windows. I personally would vote against it. AFAIK, common wisdom on Windows is to not use this. Indeed, if people felt that this behaviour was an improvement, MS would have enabled it by default at some stage over the last 10 years it has existed, and provided a way of disabling it! This behaviour causes subtle side effects; effects Unix users are well aware of, due to every single tool using it. Do the tricks needed to get the wildcard down to the program exist? Will any windows users know what they are? IMO, Windows "fixed" the Unix behaviour by dropping this, and they made a concession to die-hards by providing a rarely used way of enabling it. Windows C programmers dont expect it, VB programmers dont expect it, even batch file programmers dont expect it. I dont think we should use it.
(This is actually relevant -- it's possible that setargv.obj and glob.glob could give different answers).
Exactly. As may win32api.FindFiles(). Give the user the wildcard, and let them make sense of it. The trivial case of using glob() is so simple I dont believe it worth hiding. Your horror story of the incorrect file being deleted could then only be blamed on the application, not on Python! Mark.
[David Ascher]
A python-help poster finally convinced me that there was a way to enable automatic wildcard expansion on win32. This is done by linking in "setargv.obj" along with all of the other MS libs. Quick testing shows that it works.
Is this a feature we want to add? I can see both sides of that coin.
The only real drawback I see is that we're then under some obligation to document Python's behavior. Which is then inherited from the MS setargv.obj, which is in turn only partially documented in developer-only docs, and incorrectly documented at that.
PS: I saw a RISKS digest posting last week which had a horror story about wildcard expansion on some flavor of Windows. The person had two files with long filenames:
verylongfile1.txt and verylongfile2.txt
But Win32 stored them in 8.3 format, so they were stored as verylo~2.txt and verylo~1.txt
(Yes, the 1 and 2 were swapped!). So when he did
del *1.txt
he removed the wrong file. Neat, eh?
(This is actually relevant -- it's possible that setargv.obj and glob.glob could give different answers).
Yes, and e.g. it works this way under Win95: D:\Python>dir *~* Volume in drive D is DISK1PART2 Volume Serial Number is 1DFF-0F59 Directory of D:\Python PYCLBR~1 PAT 5,765 06-07-99 11:41p pyclbr.patch KJBUCK~1 PYD 34,304 03-31-98 3:07a kjbuckets.pyd WIN32C~1 <DIR> 05-16-99 12:10a win32comext PYTHON~1 <DIR> 05-16-99 12:10a Pythonwin TEXTTO~1 <DIR> 01-15-99 11:35p TextTools UNWISE~1 EXE 109,056 07-03-97 8:35a UnWisePW32.exe 3 file(s) 149,125 bytes 3 dir(s) 1,502,511,104 bytes free Here's the same thing in an argv-spewing console app whipped up to link setargv.obj: D:\Python>garp\debug\garp *~* 0: D:\PYTHON\GARP\DEBUG\GARP.EXE 1: kjbuckets.pyd 2: pyclbr.patch 3: Pythonwin 4: TextTools 5: UnWisePW32.exe 6: win32comext D:\Python> setargv.obj is apparently consistent with what native wildcard expansion does (although you won't find that promise made anywhere!), and it's definitely surprising in the presence of non-8.3 names. The quoting rules too are impossible to explain, seemingly random: D:\Python>garp\debug\garp "\\a\\" 0: D:\PYTHON\GARP\DEBUG\GARP.EXE 1: \\a\ D:\Python> Before I was on the Help list, I used to believe it would work to just say "well, it does what Windows does" <wink>. magnification-of-ignorance-ly y'rs - tim
[MarkH, with *the* killer argument <0.3 wink>]
Your horror story of the incorrect file being deleted could then only be blamed on the application, not on Python!
Sold! Some years ago in the Perl world, they solved this by making regular old perl.exe not expand wildcards on Windows, but also supplying perlglob.exe which did. Don't know what they're doing today, but they apparently changed their minds at least once, as the couple-years-old version of perl.exe on my machine does do wildcard expansion, and does the wrong (i.e., the Windows <wink>) thing. screw-it-ly y'rs - tim
Some years ago in the Perl world, they solved this by making regular old perl.exe not expand wildcards on Windows, but also supplying perlglob.exe which did.
This seems a reasonable way out. Just like we have pythonw.exe, we could add pythong.exe and pythongw.exe (or pythonwg.exe?). I guess it's time for a README.txt file to be installed explaining all the different executables... By default the g versions would not be used unless invoked explicitly. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (4)
-
David Ascher -
Guido van Rossum -
Mark Hammond -
Tim Peters