python 2.7.12 on Linux behaving differently than on Windows

[BartC]

On 07/12/2016 15:25, Ben Bacarisse wrote:
> BartC <bc at freeuk.com> writes:
> <snip>
>> [...] But remember:
>>
>>   cp *.c
>>
>> There might be some irate users out there if it can't detect a simple
>> user error like that.
>
> There might be.  They are ill-served by current Unix shells.  But,
> oddly, the flow has gone the other way.  People have wanted Unix shells
> and utilities ported to Windows, not cmd.exe and friends ported to
> Linux.  You clearly see a gap in the provision here.  Wouldn't it be
> better for the world if you wrote cmd.exe for Linux rather than
> complaining about what other shells do?

It's not my job to write OSes. When I started doing this stuff, either 
there was no OS, or there was just a minimal one providing file services 
and allowing you to launch applications.

Now it seems to have trouble doing even that!

(As for people wanting Linux, I don't know why that is. Maybe Linux is 
used more in colleges and people want to continue working the same way, 
maybe Linux is perceived as free and Windows a product of evil 
capitalist M$. Your guess is as good as mine.

But you might have seen my objections; even putting aside bias in favour 
of one OS or another, I think many of them are valid. That fact Linux is 
getting more popular does not mean it is always better.)

>> OK, I understand. Having a program launcher indiscriminately transform
>> input A into A' is /much/ better than having it done by the program,
>> even if the program doesn't want it and it is not meaningful.
>
> Yes, you've explained that you understand the value of such
> transformations, it's just that the ones you like happen to be exactly
> those in cmd.exe.  You are very lucky that cmd.exe happened to get
> exactly the right interpretation of the input or you would be raining
> against /every/ shell on both systems.

I can do that as well if you like!

But it just seems odd in that I've complained in the past about Python's 
method for reading interactive lines of input.

Apparently, having line input presented in one lump (a single string) 
which is then explicitly chopped up by the program into tokens, is far 
superior to any other scheme, including any of mine.

But here, having input from the command line presented as a 
ready-separated set of arguments, and with (possibly meaningless) 
expansion into multiple files to boot, is far superior to getting the 
input in one lump (a single string).

So for one kind of line input, Black is better than White; for the 
other, White is better than Black!

-- 
Bartc