python 2.7.12 on Linux behaving differently than on Windows

[Michael Torrie]

On 12/05/2016 11:50 AM, BartC wrote:
> It doesn't matter, and is not the concern of the shell. It should 
> restrict itself to the basic parsing that may be necessary when 
> parameters are separated by white-space and commas, if a parameter can 
> contain white-space or commas. That usually involves surrounding the 
> parameter with quotes.

That is just a difference of opinion and what you're used to.  A shell's
primary concern on my computer is providing a great environment for me
to work in, and for that, shell expansion is very important and useful
to me.  Also, in the Unix world (can't speak for Windows), we assemble
lots of little bash scripts into individual executable units, and string
them together. In other words, many "commands" we use in Unix are
actually little scripts themselves.  So having each and every little
script have to do its own glob expansion would be very tedious and
redundant. Moving that up to the shell makes an incredible amount of
sense given this structure.

> One would be very annoyed if, reading a CSV file, where each of N values 
> on a line correspond to a field of record, if one entry of "?LBC" 
> expanded itself to a dozen entries, screwing everything up.

I have no idea why you even put this in here.  What does reading a CSV
file have to do with glob expansion?  Sorry Bart, but you're grasping at
straws with that one.

> Shell command line processing shouldn't be attempting anything more than 
> that.

In your opinion.  Clearly there's a whole world out there that thinks
differently, and has their own good reasons.

> 
>> 	If they are command options, on a Linux shell options appear as
>>
>> X -A *.* -C -D
>>
>> Even Windows command processor separates optional/command stuff via
>>
>> X /A *.* /C /D
>>
>> ... or requires the parameter defining the file(s) to process as the last
>> arguments
> 
> Nonsense. If I pass that to a Python program that prints sys.argv, I get:
> 
> ['a.py', '/A', '*.*', '/C', '/D']
> 
> Presumably a Windows programmer is grown up enough to make their own 
> decisions as to what to do with that input.
> 
> All that's needed is one little standard library function to process 
> sys.argc, with unexpanded parameters, into a list of expanded arguments, 
> if that's really what someone wants (and then needing to trawl through 
> it all looking for the options).

Sure I understand that, and I can understand the appeal.  I just
disagree that it's this big issue you seem to think it is.

> Then you get the best of both worlds.
> 
> 
>> X A C D *.*
> 
> 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?

To add to what Chris said, all the different parameters have to be
looked at anyway, so I don't understand why it's such a burden to scan
them one by one and if they are a filename, add them to a list, if they
are a command-line argument, do something different.  And in the case of
gcc, one or more globs could appear, in any order.  So in Windows you'd
have to look at each argument anyway, and do n number of manual
expansions for non-argument parameters.  So this particular argument of
yours is rather weak.

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.