Mailing List Archive

> 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/)

On Fri, 18 Jun 1999, Guido van Rossum wrote:

> I don't see big drawbacks except minor b/w compat problems.
>
> Should it be done for both python.exe and pythonw.exe?

Sure.

> 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/)