python 2.7.12 on Linux behaving differently than on Windows

[Paul Moore]

On Monday, 5 December 2016 15:41:59 UTC, BartC  wrote:
> On 05/12/2016 15:05, Chris Angelico wrote:
> > On Tue, Dec 6, 2016 at 1:11 AM, BartC <bc at freeuk.com> wrote:
> >>
> >> BTW what does Popen() do when one argument is '*.*'? Will that get expanded
> >> to multiple extra arguments, and at what point will it be expanded?
> >
> > Nope. Popen is not a shell.
> >
> > It sounds as if you want a nerfed shell. Go ahead! I'm sure one
> > exists. It'll frustrate you no end once you get used to a better
> > shell, though - always does when I find myself on Windows...
> 
> That's not the point I was making.
> 
> Say you have this program a.py:
> 
>    import sys
>    print (sys.argv)
> 
> And let's say there are just 3 files in the current directory: a.py, 
> b.py and c.py.
> 
> If run from a Linux shell:
> 
>    python a.py *
> 
> The output is: ['a.py', 'b.py', 'c.py'] or something along those lines 
> (there might be two copies of a.py).
> 
> 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.


Python programs, when started, get a list of arguments via sys.argv.

1. On Linux, the OS primitive for executing a program takes a list of arguments and passes them directly. The user's shell is responsible for splitting a command line into "arguments".
2. On Windows, the OS primitive takes a command line. The application is responsible for splitting it into arguments, if it wants to. Most do, for compatibility with the normal argv convention inherited via C from Unix. Many programs let the C runtime do that splitting for them - I don't recall if Python does, or if it implements its own splitting these days.
3. The Popen class directly passes the supplied argv to the called program. (Technically, it has to do some nasty internal juggling to preserve the argv, but you don't need to care about that).

The program always gets a list of arguments. What *provides* that list to it (the Unix shell, the C/Python runtime, or the caller of Popen) varies. And you need (in more complex cases) to understand how the calling environment constructs that list of arguments if you want to reason about behaviour.

Paul