python 2.7.12 on Linux behaving differently than on Windows

[BartC]

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