python 2.7.12 on Linux behaving differently than on Windows

[BartC]

On 05/12/2016 18:34, eryk sun wrote:
> On Mon, Dec 5, 2016 at 3:41 PM, BartC <bc at freeuk.com> wrote:
>>
>> Are you saying that if someone executes:
>>
>>   subprocess.Popen(["python","a.py", "*"])
>>
>> the output will be: ['a.py','*']?
>>
>> In that case forget Windows vs. Linux, you now have a program that will get
>> command parameters processed differently depending on whether it was invoked
>> from a shell or not.
>>
>> Or a program that sometimes will see "*" as an argument, and sometimes a big
>> list of files that merges into all the other arguments.
>
> If it sees "*", it will try to open a file named "*".

And people still say that the way Windows works is crazy!

  That's a valid
> filename in Unix, but it should be avoided.

No, it should be prohibited, if the file API and/or shell assign special 
significance to it.

> I don't understand your concern regarding Unix shell scripting syntax.
> On Windows, are you as troubled that environment variables such as
> %USERNAME% get expanded by cmd.exe, but not by CreateProcess?

No, because I never use %USERNAME%, and it is obviously something 
associated with Windows' Batch language which I hardly ever use.

Not like file wildcards, which I use all the time, and don't associate 
them exclusively with a shell.

I also never expect any parameter that contains ? and * to be expanded 
then and there to whatever list of files there might happen to be. Maybe 
the files haven't been created yet, maybe the parameter has got NOTHING 
TO DO with filenames.

(For example, in Windows:

    >ren *.c *.d

Rename all .c files to .d files. None of the .d files exist (or, because 
of the point below, some isolated .d file exists). I wouldn't be able to 
emulate such a command under Linux, not without writing:

   rename *.c "*.d"

or even:

   rename "*.c" "*.d"

since, if the user forgets the second parameter, and there were two .c 
files, it would think I wanted to rename one .c file to another.)

But that leads to another weird behaviour I've just observed: if a 
parameter contains a filespec with wildcards, and there is at least one 
matching file, then you get a list of those files.

However, if there are no matching files, you get the filespec unchanged.

Now, what is a program supposed to with that? It seems it has to deal 
with wildcards after all. But also some behaviours can become erratic. 
This program asks for the name of a DAB radio station:

   >station ?LBC

Fine, the input is ?LBC (which is an actual station name where I live). 
But then at some point a file ALBC comes into existence; no connection. 
Now the same line gives the input ALBC, to perplex the user!

> Every command-line shell that I've ever used is also a quirky
> scripting language.

It seems shell language authors have nothing better to do than adding 
extra quirky features that sooner or later are going to bite somebody 
on the arse. Mainly I need a shell to help launch a program and give it 
some basic input; that's all.

(The people who think up obscure hot-key combinations belong in the same 
camp. I keep hitting key combinations that do weird things, then have to 
find a way out. One combination turned the display upside-down! Then I 
had to turn the monitor upside down while I investigated solutions.)

-- 
Bartc