python 2.7.12 on Linux behaving differently than on Windows
greg.ewing at canterbury.ac.nz
Tue Dec 6 01:28:52 EST 2016
> On 05/12/2016 19:29, Michael Torrie wrote:
>> On 12/05/2016 11:50 AM, BartC wrote:
>>> So how do I do:
>>> gcc *.c -lm
>>> The -lm needs to go at the end.
>>> Presumably it now needs to check each parameter seeing if it resembles a
>>> file more than it does an option? And are options automatically taken
>>> care of, or is that something that, unlike the easier wildcards, need to
>>> be processed explicitly?
> This was a response to someone saying the wildcard param needs to be at
> the end. There need be no such restriction if handled properly (ie. no
> But a similar example, suppose a syntax is:
> appl *.* [options]
> but one of the files in the list is called "-lm", or some other option
> that can do things the user didn't want (with gcc, -lm is harmless).
> Without expansion, input is easy to parse: filespec, followed by
> optional options. But with expansion, now you have to decide if a
> particular argument is an option, or a filename.
> And if there's an error in an option, you may have to abort, which means
> throwing away that list of files which, in some cases, can run into
>> Not having glob expansion be in individual programs makes things much
>> more explicit, from the program's point of view. It provides an
>> interface that takes filename(s) and you provide them, either explicitly
>> (via popen with no shell), or you can do it implicitly but in an
>> interactive way via the shell using expansion. Personal preference but
>> I believe it's a much better way because it's explicit from the
>> program's point of view as there's no question about the program's
>> Different strokes for different folks as they say.
> I must have given ten or twenty scenarios where such auto-expansion is
> problematical. And yet people are still in denial. It's been in Unix for
> decades therefore there's nothing wrong with it!
> But maybe people simply avoid all the situations that cause problems.
> Interfaces are specified in a certain manner, given that input can be
> any long stream of filenames and/or options with no order and no
> positional significance. Non-file parameters that use ? or * are
> prohibited. You can't do the equivalent of:
> >DIR *.b *.c
> And get a list of *.b files, with a heading and summary lines, then a
> list of *.c files with its own heading and summary. It would be one
> monolithic list.
> So everyone is working around the restrictions and the problems. Which
> is exactly what I would have to do.
> That doesn't change the fact that the Windows approach is considerably
> more flexible and allowing more possibilities.
More information about the Python-list