On 04/12/2016 23:25, Steve D'Aprano wrote:
On Mon, 5 Dec 2016 09:19 am, BartC wrote:
Command parameters /do/ behave differently between Windows and Linux,
for example try writing *.* as that third parameter.
In Windows, it will print *.*.
In Linux, if you have 273 files in the current directory, if will print
the name of the first, and there will be /272 further command
parameters/, each the name of a file. (I couldn't believe this when I
found out; one of my directories recently had 3.4 million files in it, I
don't really want *.* expanded to 3.4m arguments. Here, the fix is again
to use double quotes: "*.*". But what if the user doesn't do that?)
If the user doesn't escape the wildcard, then the shell will expand it,
exactly as the user would expect.
I'm not sure why you were surprised by that. * is a shell wildcard. By using
a * you are explicitly telling the shell to expand it to any file that
matches.
I don't know what a shell is. To me, it's some sort of user interface to
the OS. So if someone types:
> X A B C
You would expect X to be launched, and be given arguments A, B and C.
You wouldn't expect any of them to be expanded to some unknown number of
arguments.
In the same way that in code, you don't expect X(A,B,C) to be expanded
to X(A,B0,B1,B2,B3,B4,B5,....., C) if B happens to specify a slice.
Did you think it was a regular character like 'a' and 'z'?
If one of the parameters was a regular expression, would you expect it
to be expanded to the entire possible set of inputs that match the
expression?
I think it boils down to what the user expects. Linux and Unix users tend to
be technically-minded folks who use the command line a lot and demand
powerful tools, and they expect that wildcards like * should be expanded.
Which is dumb. How does the shell know exactly what I want to do with
*.* or f*.c or whatever? Perhaps I don't want the expanded list right
now (all the 3.4 million elements); perhaps I want to apply the same
pattern to several directories; perhaps I'm passing it on to another
program; perhaps I'm going to be writing it as another script; perhaps I
just want to print out the parameter list; perhaps I want to transform
or validate the pattern first; maybe I need to verify an earlier
parameter before applying the pattern or the way it's applied depends on
earlier arguments...
The input is a PATTERN; I want to process it, and apply it, myself.
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.
What happens here:
>X *.a *.b *.c
It'll just get one big long list of files, not three separate sets.
As I said, it's dumb. And expecting users to stick quotes everywhere is
not a solution, because that's not going to happen.
Windows treats the command line as an afterthought, and until a few years
ago you were limited to a DOS shell. Today, your options are not as
limited: there's Powershell, and bash for Windows.
At least Windows does it properly. It doesn't even chop the command line
into different parameters, making it considerably more flexible. (Unless
you have a program based on a C-style main(nargs,args) entry point where
the C runtime will do this for you.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
