python 2.7.12 on Linux behaving differently than on Windows

[Gregory Ewing]

BartC wrote:
> 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 
> auto-expansion).
> 
> 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 
> millions.
> 
>> 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 
>> behavior.
>>
>> 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.
>