python 2.7.12 on Linux behaving differently than on Windows

[Anton Mamaenko]

Wow... this thread gets to finally become a holy war.  One method is dealing with this is take the environment as granted (Windows/Unix/Linux/MacOS/Dos sucks while my 
Windows/Unix/Linux/MacOS/Dos is the best) and figure if the hassle of porting (time, tech, AND moral) worth it. He just "do not try. Do or not do."

So stop complaining. Just live with it. 

Regards,
       Anton

> On 7 Dec 2016, at 21:02, BartC <bc at freeuk.com> wrote:
> 
>> 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
> -- 
> https://mail.python.org/mailman/listinfo/python-list