python 2.7.12 on Linux behaving differently than on Windows
bc at freeuk.com
Mon Dec 5 14:24:21 EST 2016
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"
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:
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.)
More information about the Python-list