On 05/12/2016 17:46, Dennis Lee Bieber wrote:
On Mon, 5 Dec 2016 11:42:08 +0000, BartC <b...@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
--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to