python 2.7.12 on Linux behaving differently than on Windows

[BartC]

On 07/12/2016 16:53, Michael Torrie wrote:
> On 12/07/2016 08:48 AM, BartC wrote:
>> I would prefer that the program "t" can be invoked exactly the same way
>> under both systems. I don't want different instructions for Linux, or
>> for the user (of my language) to have to write two lots of code, as that
>> is my job...
>
> Ahh now we come to the crux of your argument.  You want all potential
> platforms to conform to your own idea of what is normal.  And indeed
> this is the actual issue that started the original thread.  But that's
> not the way it works for any platform.  I develop a lot of code on Linux
> that I'd like to get running on Windows.  I prefer the Linux way of
> doing things but I'm not going to make any headway if I just try to
> brow-beat Windows and Windows' users over the things that aren't
> implement the same way.

There is a lack of balance.

If I run a Linux program on Windows, then the application gets to see 
parameters such as *.* and can expand them if it wants.

If I want to run a Windows program on Linux, and that program needs to 
see *.* unexpanded, then it can't undo that expansion. The cat is 
already out of the bag.

It seems the only choice, if someone wants a cross-platform application 
that is invoked in the same way, is to dumb it down and make it assume 
that any parameters such as A* have been expanded, or will be expanded 
by that extra step.

Which means that input of A B* *C will all end up running together so 
that you have no idea what is what or which file corresponds to which 
expansion. That's assuming these parameters have any connection to the 
current set of files at all; if not, then the input you end up is going 
to be meaningless.

Now the problem is to determine whether processed input of U V W X Y Z 
are intended bona fide inputs, or whether they just happened to result 
from some random associations with the files in the current directory.

But this is what happens when you have to work to the lowest common 
denominator. The only proper solution is ban any unescaped ? or * from 
inputs, and to add a warning that the program could behave unexpectedly 
if they are used inadvertently.

(I'm in the middle of porting my console editor to Linux. But one 
problem is that on one Linux, half the key combinations (eg. 
Shift+Ctrl+B) are not recognised. On other Linux, nearly all of those 
are missing too, plus most of the rest! Which means I have to adapt the 
editor, again, to the lowest common denominator, the minimum set of keys 
that are guaranteed to work on both.

Except that was only two Linuxes; perhaps on others, the keyboard will 
likely be crippled in some other way. That is, the same universal USB 
keyboard that you can buy anywhere for $5 or $10, which has keys marked 
Shift, Ctrl and Alt, but whose combinations cannot be recognised 
consistently.

How people manage to do anything on such an OS I've no idea. Or maybe 
they spend all day just typing elaborate file-matching patterns to pipe 
between applications.)

-- 
Bartc