python 2.7.12 on Linux behaving differently than on Windows

[Lew Pitcher]

On Monday December 5 2016 11:23, in comp.lang.python, "BartC" <bc at freeuk.com>
wrote:

> On 05/12/2016 15:53, Chris Angelico wrote:
>> On Tue, Dec 6, 2016 at 2:41 AM, 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.
>>
>> Yes, that is correct. *SHELLS DO STUFF*. If you can't comprehend this,
>> you should get to know your shell. Try this:
>>
>> python a.py %PATH%
>>
>> subprocess.Popen(["python", "a.py", "%PATH%"])
>>
>> Would you expect those to do the same? If you do, prepare for Windows
>> to surprise you. If you don't, why do you keep expecting other shells
>> to do nothing?
> 
> You still don't get point. I write a program P, a native executable. It
> takes command line parameters but exactly what it gets depends on
> whether it's started from a 'shell' or from inside another program?

In Unix, it always has.


> I 
> don't want to worry about that stuff or exactly how it is invoked!

Then, I guess that you have a problem, don't you?

>  > subprocess.Popen(["python", "a.py", "%PATH%"])
> 
> Yes, %...% is an escape sequence. Those % signs are supposed to stand
> out and have been chosen not to clash with typical input.
> 
> And the end result of the transformation is, here, also a SINGLE thing;
> any parameter following will still be the second parameter, not the 14771th!
> 
> Are you saying that the * in ABC*EF also makes the whole thing some
> escape pattern?

If you ask the shell to parse the arguments, then, "YES, the * in ABC*EF makes
the argument a candidate for globbing".

> And one that could massively expand the number of parameters,

Yes

> pushing all the following ones out of the way, and making it 
> impossible to discover where these expanded parameters end and the
> normal ones recommence.

The best way to think about it is that all parameters are parameters, whether
derived from a glob input to a shell, or explicitly specified in the
invocation.

If you have a need for positional parameters, then either specify that your
code only accepts them in specific places, or find a way to disable globbing
(it can be done) and handle the expansion yourself, in your own code.

> If someone had thought this up now, it would rapidly be dismissed as
> being unworkable. But because it's been in Unix/Linux/whatever so long,
> no one can see anything wrong with it!

Primarily because there /IS/ nothing wrong with it.

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request