python 2.7.12 on Linux behaving differently than on Windows
eryksun at gmail.com
Mon Dec 5 13:34:55 EST 2016
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 "*". That's a valid
filename in Unix, but it should be avoided. We wouldn't want someone
to accidentally run `rm *` instead of `rm \*`.
In Windows, it's invalid for filenames to include wildcard characters
(i.e. '*' and '?' as well as the MS-DOS compatibility wildcards '<',
'>', and '"' -- DOS_STAR, DOS_QM, and DOS_DOT). Since there's no
ambiguity of intent, if you've linked an executable with
[w]setargv.obj, the C runtime will happily expand "*" in the argv
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? Does it
bother you that cmd consumes its "^" escape character if it's not
escaped as "^^"? For example:
C:\>python.exe -i -c "" remove: ^ keep: ^^
>>> import win32api
'python.exe -i -c "" remove: keep: ^'
Every command-line shell that I've ever used is also a quirky
scripting language. Shell literacy requires learning at least the
syntax and operators of the language.
More information about the Python-list