[issue12505] python interpreter not handle wildards properly

2011-07-06 Thread Brian Curtin

Changes by Brian Curtin :


--
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12505] python interpreter not handle wildards properly

2011-07-06 Thread yoch

yoch  added the comment:

Okay. Thanks :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12505] python interpreter not handle wildards properly

2011-07-06 Thread Sebastian Ramacher

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__":
  if len(sys.argv) == 1:
subprocess.Popen([sys.executable, __file__, "foo", "*"])
  else:
print sys.argv[1:]

With setargv.obj the argument would be expanded on Windows whereas on any other 
platform it just prints [foo, *].

--
nosy: +sebastinas

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12505] python interpreter not handle wildards properly

2011-07-06 Thread Eric V. Smith

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 to:
python '"*"'

I'm just pointing out that it's a change for some users, and might break some 
existing usage of python. I can't say whether or not that's a big problem or 
not.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12505] python interpreter not handle wildards properly

2011-07-06 Thread yoch

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 main(). Or am I missing 
something? (entirely possible, it's been a while since I've used setargv.obj)
[/q]
I dont't know. But what difference does it make, after all?
( I'm not sure I understand, my english is poor ;) )

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12505] python interpreter not handle wildards properly

2011-07-06 Thread Eric V. Smith

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, documentation of setargv.obj is sparse).

Of course this would be true from any shell, I'm just familiar with the syntax 
of doing so under bash.

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 main(). Or am I missing 
something? (entirely possible, it's been a while since I've used setargv.obj)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12505] python interpreter not handle wildards properly

2011-07-06 Thread yoch

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 
expanding) to work only with cygwin ...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12505] python interpreter not handle wildards properly

2011-07-06 Thread Eric V. Smith

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12505] python interpreter not handle wildards properly

2011-07-06 Thread yoch

yoch  added the comment:

Escape the wildcard like '*' will work (like on Linux).

I think \* will not work...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12505] python interpreter not handle wildards properly

2011-07-06 Thread Eric V. Smith

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 in this 
case, and I don't see how it could know not to do it.

--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12505] python interpreter not handle wildards properly

2011-07-06 Thread yoch

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 msvc, as mentioned here:
http://msdn.microsoft.com/en-us/library/8bch7bkk.aspx

Regards,
yoch

--
components: Windows
files: test_argv_1.py
messages: 139930
nosy: yoch.melka
priority: normal
severity: normal
status: open
title: python interpreter not handle wildards properly
versions: Python 3.2
Added file: http://bugs.python.org/file22592/test_argv_1.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com