python 2.7.12 on Linux behaving differently than on Windows

[BartC]

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.

-- 
Bartc