python 2.7.12 on Linux behaving differently than on Windows
antoon.pardon at rece.vub.ac.be
Wed Dec 7 15:37:13 EST 2016
Op 07-12-16 om 19:02 schreef 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.
You should stop trying to frame this as a need of the program. If it was just about the program needing to see *.* as an
argument. That is possible. Just quote the argument.
But this isn't about what a program would need, this is about how you would like things to work. You have some points I
agree with, but I don't think those points weight heavy enough to get people changing things on the unix side.
> 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.
cross-platform applications will always need to come to some kind of compromise.
> 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.
Yes and the point is? If you write a cross-platform application and you don't consider how the environments differ
then you might end up with something 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.
No it is not. Making this your problem is just an untractable mess and it is not limited to globbing. Suppose I
have a file named -rf and want it among other files removed. I don't consider it more closely and just type:
rm -rf ...
How is your program going to decide between me wanting to remove the file '-rf' and me wanting the options?
You don't like how it generally works on unix. Too bad for you when you have to work on a unix box.
Me I don't like how it generally works on a windows. Too bad for me when I find myself without
a choice but to work on a windows box. Life just isn't easy and fair.
More information about the Python-list