BartC wrote:
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.
--
https://mail.python.org/mailman/listinfo/python-list
