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