[ python-Bugs-1436900 ] Problem parsing cmdline parameter quoted with a trailing \
Bugs item #1436900, was opened at 2006-02-22 10:38
Message generated for change (Comment added) made by tungwaiyip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem parsing cmdline parameter quoted with a trailing \
Initial Comment:
This problem happens in launching Python from Windows.
A quoted pathname is used as parameter. If and only if
the pathname is ended with a trailing \, it is treated
as an escape character.
p.py
---
import sys
from pprint import pprint
pprint(sys.argv)
---
Note slash inside the quote is treated as path
separators
g:\usr\bin>c:\python24\python.exe g:\usr\bin\p.py "
tung\wai\yip" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip', 'wai']
However the trailing \ is treated as an escape
character for the quote. Only command line parameter
is presented in sys.argv.
g:\usr\bin>c:\python24\python.exe g:\usr\bin\p.py "
tung\wai\yip\" wai
['g:\\usr\\bin\\p.py', 'tung\\wai\\yip" wai']
--
>Comment By: Wai Yip Tung (tungwaiyip)
Date: 2006-02-23 09:35
Message:
Logged In: YES
user_id=561546
I don't completely follow your logic. But I have reproduce
this with Java so it looks very likely that it is a Windows
bug. In addition, a workaround is to add as extra \ at the
end of the first argument if you know it is going to end in
\. This is illustrated in the last example.
P.java
public class P {
public static void main(String argv[]) throws Exception {
for (int i=0; i < argv.length; i++) {
System.out.println("argv " + i + " " + argv[i]);
}
}
}
---
BAD
c:\>java P "tung\wai\yip\" wai
argv 0 tung\wai\yip" wai
GOOD
c:\>java P "tung\wai\yip\\" wai
argv 0 tung\wai\yip\
argv 1 wai
---
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 12:53
Message:
Logged In: YES
user_id=849994
OK, closing.
--
Comment By: splitscreen (splitscreen)
Date: 2006-02-22 12:38
Message:
Logged In: YES
user_id=1126061
Whoops, my bad. Its a windows issue, not a python one.
--
Comment By: splitscreen (splitscreen)
Date: 2006-02-22 12:34
Message:
Logged In: YES
user_id=1126061
After having a quick look it appears as though python is in
fact stripping the trailing '\'. the argv array that the
python interpreter is passed contains the backslash so it
must be doing away with it.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-02-22 12:12
Message:
Logged In: YES
user_id=849994
Is that Python-specific? I thought sys.argv is the cmdline
args as Python gets them from Windows.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436900&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1194328 ] Reading from a killed shell script with popen* under linux
Bugs item #1194328, was opened at 2005-05-03 09:44
Message generated for change (Comment added) made by boukthor
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: Vinz (boukthor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reading from a killed shell script with popen* under linux
Initial Comment:
These are problems I've run into under linux (Mandrake
10.0 through 2006.0, Debian 3.1 and Gentoo) with python
versions ranging from 2.3.3 to 2.4:
If you run this:
import os
pout = os.popen("/bin/sleep 999")
print pout.read()
print pout.close()
and kill the "sleep", you get the desired behaviour:
the read returns an empty string when the process gets
killed and the close returns the killing signal.
However, if you put the "sleep" command in a shell
script, for example this simple "/tmp/test.sh":
#!/bin/sh
sleep 999
and run the script through popen (or one of the popen*
method of the os and popen2 module)
import os
pout = os.popen("/tmp/test.sh")
print pout.read()
print pout.close()
then kill the sh running "test.sh", the read never
returns and the shell remains as a zombie. You can get
some strange behaviour with the Popen* classes too
(whether bypassing the shell intervention or not). For
example, run this (and kill the subshell):
import popen2
sub = popen2.Popen3("/tmp/test.sh")
print sub.wait()
print sub.fromchild.read()
this time the wait correctly returns the signal that
killed the shell and removes it from the process table,
but the read hangs again.
As an added oddity, if you run the popen command from
an interactive prompt and raise a KeyboardInterrupt by
pressing Ctrl-C before trying to read from the pipe,
you kill the subprocess with the SIGINT...
I have a final suggestion: if you try reading the
output of a popen* method with a "for" statement like this:
import os
pout = os.popen("for i in $(seq 1 10); do echo $i;
sleep 1; done")
for l in pout: print l,
it waits for the subprocess to complete before going
into the loop. To get the output as it is piped, you
have to use the poll method of the Popen* classes
(which is not available under OSes other than Unix):
sub = popen2.Popen3("for i in $(seq 1 10); do echo $i;
sleep 1; done")
while (-1 == sub.poll()): print sub.fromchild.readline()
I don't know if this last behaviour can be fixed or not
but I'd suggest some mention of this in the manual if
it can't.
--
>Comment By: Vinz (boukthor)
Date: 2006-02-23 19:02
Message:
Logged In: YES
user_id=638508
This is not a bug after all...
When you run a command through a shell script, kill the
script and waiting for it to return, any subcommands of the
script get reattached to init until they complete. If these
subcommands didn't close them, they still have descriptors
to the popen pipe through which they may write data. It is
then normal that reading the pipe should block until
completion, not only of the command invoqued but of all its
subprocesses as well. Very annoying for my purpose, but
definitively not a python bug.
Oh well, I thinks I'll stop talking to myself, now. I must
say I'm a bit disappointed at the nonexistent support and
help I got from this python bugzilla, though...
--
Comment By: Vinz (boukthor)
Date: 2005-08-12 13:48
Message:
Logged In: YES
user_id=638508
The report #1180160 was only loosely related to the above
problem. In fact it is probably closer to the following :
761888 popen2.Popen3 and popen2.Popen4 leaks filedescriptors
892939 Race condition in popen2
998246 Popen3.poll race condition
1183780 Popen4 wait() fails sporadically with threads
NB : This bug is very incapacitating for me since I can't
figure any workaround and though I understand that
developers may have other priorities, I'd appreciate some
acknowledgement that somebody at least read this report...
--
Comment By: Vinz (boukthor)
Date: 2005-05-03 09:49
Message:
Logged In: YES
user_id=638508
Oops, just saw the report #1180160. I missed it because I
searched for popen, not Popen before posting. My bad. I'll
cross-reference the two.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1194328 ] Reading from a killed shell script with popen* under linux
Bugs item #1194328, was opened at 2005-05-03 09:44
Message generated for change (Settings changed) made by boukthor
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Vinz (boukthor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reading from a killed shell script with popen* under linux
Initial Comment:
These are problems I've run into under linux (Mandrake
10.0 through 2006.0, Debian 3.1 and Gentoo) with python
versions ranging from 2.3.3 to 2.4:
If you run this:
import os
pout = os.popen("/bin/sleep 999")
print pout.read()
print pout.close()
and kill the "sleep", you get the desired behaviour:
the read returns an empty string when the process gets
killed and the close returns the killing signal.
However, if you put the "sleep" command in a shell
script, for example this simple "/tmp/test.sh":
#!/bin/sh
sleep 999
and run the script through popen (or one of the popen*
method of the os and popen2 module)
import os
pout = os.popen("/tmp/test.sh")
print pout.read()
print pout.close()
then kill the sh running "test.sh", the read never
returns and the shell remains as a zombie. You can get
some strange behaviour with the Popen* classes too
(whether bypassing the shell intervention or not). For
example, run this (and kill the subshell):
import popen2
sub = popen2.Popen3("/tmp/test.sh")
print sub.wait()
print sub.fromchild.read()
this time the wait correctly returns the signal that
killed the shell and removes it from the process table,
but the read hangs again.
As an added oddity, if you run the popen command from
an interactive prompt and raise a KeyboardInterrupt by
pressing Ctrl-C before trying to read from the pipe,
you kill the subprocess with the SIGINT...
I have a final suggestion: if you try reading the
output of a popen* method with a "for" statement like this:
import os
pout = os.popen("for i in $(seq 1 10); do echo $i;
sleep 1; done")
for l in pout: print l,
it waits for the subprocess to complete before going
into the loop. To get the output as it is piped, you
have to use the poll method of the Popen* classes
(which is not available under OSes other than Unix):
sub = popen2.Popen3("for i in $(seq 1 10); do echo $i;
sleep 1; done")
while (-1 == sub.poll()): print sub.fromchild.readline()
I don't know if this last behaviour can be fixed or not
but I'd suggest some mention of this in the manual if
it can't.
--
Comment By: Vinz (boukthor)
Date: 2006-02-23 19:02
Message:
Logged In: YES
user_id=638508
This is not a bug after all...
When you run a command through a shell script, kill the
script and waiting for it to return, any subcommands of the
script get reattached to init until they complete. If these
subcommands didn't close them, they still have descriptors
to the popen pipe through which they may write data. It is
then normal that reading the pipe should block until
completion, not only of the command invoqued but of all its
subprocesses as well. Very annoying for my purpose, but
definitively not a python bug.
Oh well, I thinks I'll stop talking to myself, now. I must
say I'm a bit disappointed at the nonexistent support and
help I got from this python bugzilla, though...
--
Comment By: Vinz (boukthor)
Date: 2005-08-12 13:48
Message:
Logged In: YES
user_id=638508
The report #1180160 was only loosely related to the above
problem. In fact it is probably closer to the following :
761888 popen2.Popen3 and popen2.Popen4 leaks filedescriptors
892939 Race condition in popen2
998246 Popen3.poll race condition
1183780 Popen4 wait() fails sporadically with threads
NB : This bug is very incapacitating for me since I can't
figure any workaround and though I understand that
developers may have other priorities, I'd appreciate some
acknowledgement that somebody at least read this report...
--
Comment By: Vinz (boukthor)
Date: 2005-05-03 09:49
Message:
Logged In: YES
user_id=638508
Oops, just saw the report #1180160. I missed it because I
searched for popen, not Popen before posting. My bad. I'll
cross-reference the two.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1437614 ] can't send files via ftp on my MacOS X 10.3.9
Bugs item #1437614, was opened at 2006-02-23 11:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Li Quid (liquid333) Assigned to: Nobody/Anonymous (nobody) Summary: can't send files via ftp on my MacOS X 10.3.9 Initial Comment: When trying to do a simple ftp upload using Python 2.3's ftplib, it fails and I get a socket error. The exact error is (61, 'Connection refused'). This happens to me in all my scripts that use the ftplib on MacOS 10.3.9, but not in scripts on my Windows box. I've attached the small, simple source code. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437614&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1437699 ] robotparser crashes if robots.txt contains non-ASCII
Bugs item #1437699, was opened at 2006-02-23 16:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437699&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: robotparser crashes if robots.txt contains non-ASCII
Initial Comment:
One-line summary: If the robotparser module encounters
a robots.txt file that contains non-ASCII characters
AND I pass a Unicode user agent string to can_fetch(),
that function crashes with a TypeError under Python
2.4. Under Python 2.3, the error is a UnicodeDecodeError.
More detail:
When one calls can_fetch(MyUserAgent, url), the
robotparser module compares the UserAgent to each user
agent described in the robots.txt file. If
isinstance(MyUserAgent, str) == True then the
comparison does not raise an error regardless of the
contents of robots.txt. However, if
isinstance(MyUserAgent, unicode) == True, then Python
implicitly tries to convert the contents of the
robots.txt file to Unicode before comparing it to
MyUserAgent. By default, Python assumes a US-ASCII
encoding when converting, so if the contents of
robots.txt aren't ASCII, the conversion fails. In other
words, this works:
MyRobotParser.can_fetch('foobot', url)
but this fails:
MyRobotParser.can_fetch(u'foobot', url)
I recreated this with Python 2.4.1 on FreeBSD 6 and
Python 2.3 under Darwin/OS X. I'll attach examples from
both. The URLs that I use in the attachments are from
my Web site and will remain live. They reference
robots.txt files which contain an umlaut-ed 'a' (0xe4
in iso-8859-1). They're served up using a special
.htaccess file that adds a Content-Type header which
correctly identifies the encoding used for each file.
Here's the contents of the .htaccess file:
AddCharset iso-8859-1 .iso8859-1
AddCharset utf-8 .utf8
A suggested solution:
AFAICT, the construction of robots.txt is still defined
by "a consensus on 30 June 1994 on the robots mailing
list" [http://www.robotstxt.org/wc/norobots.html] and a
1996 draft proposal
[http://www.robotstxt.org/wc/norobots-rfc.html] that
has never evolved into a formal standard. Neither of
these mention character sets or encodings which is no
surprise considering that they date back to the days
when the Internet was poor but happy and we considered
even ASCII a luxury and we were grateful to have it.
("ASCII? We used to dream of having ASCII. We only had
one bit, and it was a zero. We lived in a shoebox in
the middle of the road..." etc.) A backwards-compatible
yet forward-looking solution would be to have the
robotparser module respect the Content-Type header sent
with robots.txt. If no such header is present,
robotparser should try to decode it using iso-8859-1
per section 3.7.1 of the HTTP 1.1 spec
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1)
which says, 'When no explicit charset parameter is
provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of
"ISO-8859-1" when received via HTTP. Data in character
sets other than "ISO-8859-1" or its subsets MUST be
labeled with an appropriate charset value.' Section
3.6.1 of the HTTP 1.0 spec says the same. Since
ISO-8859-1 is a superset of US-ASCII, robots.txt files
that are pure ASCII won't be affected by the change.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437699&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1437785 ] Problems w/ expat 1.95.7 vs. Python 2.4
Bugs item #1437785, was opened at 2006-02-23 17:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Problems w/ expat 1.95.7 vs. Python 2.4 Initial Comment: This may apply to the trunk as well... Today I finished installing 2.4.2 and all our local libraries at work. Trying out the main application I use I discovered Python segfaulting when trying to import pyexpat. It turned out that during the import an earlier module (gtk.glade) also wanted libexpat. Apparently pyexpat was expecting to get Expat 1.95.8 (what's delivered with Python) but got 1.95.7 instead (what we had installed and what was already linked with all our other Expat-using code). The solution was rather simple. I just commented out those constants in the pyexpat initialization that were marked as 1.95.8. Fortunately there was a comment identifying the version dependency. Is there some way that Python's build process can detect the Expat version and conditionally include/exclude bits that are for later versions? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
