[issue12505] python interpreter not handle wildards properly

Changes by Brian Curtin : -- resolution: -> invalid stage: -> committed/rejected status: open -> closed type: -> behavior ___ Python tracker ___ __

[issue12505] python interpreter not handle wildards properly

yoch added the comment: Okay. Thanks :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue12505] python interpreter not handle wildards properly

Sebastian Ramacher added the comment: That is definitely not python's job. That is the duty of your shell and python should never expand that. And it would lead to platform specific behavior as one can see with the following script: import sys import subprocess if __name__ == "__main__":

[issue12505] python interpreter not handle wildards properly

Eric V. Smith added the comment: > I dont't know. But what difference does it make, after all? I just want to make sure it's something that happens automatically and wouldn't require a change to python's C code. To the other point, someone who currently uses: python '*' would need to change t

[issue12505] python interpreter not handle wildards properly

yoch added the comment: With cmd and program compiled with setargv.obj, 'command *' is expanded, but not 'command "*"'. So, it's possible to escape them normally. [q] While it might be a separate .obj file, I believe it's still part of the logical C runtime that gets invoked before python's m

[issue12505] python interpreter not handle wildards properly

Eric V. Smith added the comment: I'm not suggesting they use cygwin. I'm saying that if they do use cygwin that something they currently do would stop working. There would be no way to pass a command line parameter of "*" to python, at least without adding more escaping (hard to say, document

[issue12505] python interpreter not handle wildards properly

yoch added the comment: 'setargv.obj' not C runtime, it's only static library to allow expanding wildcards arguments received by the program. (MinGW uses approximately the same principle for executables compilation) And, it's not appropriate to tell people who need this feature (arguments ex

[issue12505] python interpreter not handle wildards properly

Eric V. Smith added the comment: Both of them work under cygwin. My point is that neither would work if the C runtime expanded command line arguments. -- ___ Python tracker ___

[issue12505] python interpreter not handle wildards properly

yoch added the comment: Escape the wildcard like '*' will work (like on Linux). I think \* will not work... -- ___ Python tracker ___ __

[issue12505] python interpreter not handle wildards properly

Eric V. Smith added the comment: But what if you don't want the expansion done? I always invoke python from cygwin's bash shell, and sometimes I tell the shell not to expand the arguments, such as: python \* or python '*' I wouldn't want python (or rather the C runtime) to do the expansion i

[issue12505] python interpreter not handle wildards properly

New submission from yoch : Hi, I'm using sys.argv to retrieve files and process them on the command line. Wildcards arguments (like : test.py *.txt) works fine under Linux (expanded), but not on Windows. It also affects the fileinput functions. The solution is to change the compilation options