python 2.7.12 on Linux behaving differently than on Windows

[eryk sun]

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
list.

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
    >>> win32api.GetCommandLine()
    '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.