python 2.7.12 on Linux behaving differently than on Windows

BartC bc at freeuk.com
Mon Dec 5 13:50:30 EST 2016


On 05/12/2016 17:46, Dennis Lee Bieber wrote:
> On Mon, 5 Dec 2016 11:42:08 +0000, BartC <bc at freeuk.com> declaimed the
> following:
>
>
>> And it doesn't work anyway; suppose I write:
>>
>>   >X A *.* C D
>>
>> How does the program know when the expanded filenames of *.* end, and
>> the two extra parameters start? Remember it doesn't know there were four
>> parameters, all it seems is one linear stream of arguments. Any
>> structure the input may have had is lost.
>>
> 	And just what ARE A, C, and D?

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.

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.

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

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

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?

-- 
Bartc



More information about the Python-list mailing list