[ python-Bugs-1057048 ] subprocess works poorly on Windows with Python 2.3
Bugs item #1057048, was opened at 2004-10-29 21:24
Message generated for change (Comment added) made by chas17360
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1057048&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.4
Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess works poorly on Windows with Python 2.3
Initial Comment:
My understanding was that subprocess.py was supposed to be
backwards compatible with at least Python 2.3 if not 2.2. Wanting
subprocess and backwards compatibility, I grabbed the subprocess.py
from 2.4b1, changed the import if so that win32api was used (since I
had no _subprocess library!) and found several problems, of which
this is one (one per bug report):
If the executable has a space in its path name (as is standard on
Windows) and command-line arguments, things fail miserably:
from subprocess import *
Popen('"C:\\Program Files\\ds9\\xpaget" ds9 mode')
produces an error that C:\Program cannot be run. Clearly the double
quoting isn't making it through Popen. Note that this runs just fine if
there are no command line arguments, i.e. this works:
Popen('"C:\\Program Files\\ds9\\xpaget"')
Note that this same bug also exists in os.popen3, so you may have
inherited it.
This bug does NOT occur on a unix build on MacOS X.
--
Comment By: chas17360 (chas17360)
Date: 2006-12-13 13:02
Message:
Logged In: YES
user_id=1667498
Originator: NO
I may have found a related problem:
The following appears in function list2cmdline():
elif c == '"':
# Double backspaces.
result.append('\\' * len(bs_buf)*2)
bs_buf = []
result.append('\\"')
i.e. the character(s) being checked is a double quote, but the comment
states 'Double backspaces'. The code as it is (using Python25) causes a
problem when trying to perform a Windows XP copy on a file with whitespace
in it's name. The problem does not occur if the double quote in the code
above is replaced by 2 back ticks.
--
Comment By: Russell Owen (reowen)
Date: 2004-11-17 22:03
Message:
Logged In: YES
user_id=431773
I tried to follow up on this and today I cannot get it to fail on my
system. I
suggest suspending or closing the bug report. If I figure out what was
going
on and it still seems to be a bug, I'll reopen or file a new report. Sorry
for the
trouble (and thanks for fixing the problem with opening console windows on
Windows).
--
Comment By: Peter Åstrand (astrand)
Date: 2004-11-07 16:18
Message:
Logged In: YES
user_id=344921
I don't have a "c:\program files" directory on my system,
since it's a Swedish version of Windows. I've tested with
"c:\program\internet explorer\iexplore.exe" instead, but
cannot reproduce the problem: Not with subprocess with 2.4
or 2.3, and not with os.popen3 either. For example, I've tried:
w, r, x = os.popen3('"c:\\program\\internet
explorer\iexplore.exe" www.abc.se')
Please test and see if you can reproduce the problem with
Internet Explorer.
As far as I know, it should be safe to install 2.4b1 without
trashing the 2.3 installation.
--
Comment By: Russell Owen (reowen)
Date: 2004-11-03 19:11
Message:
Logged In: YES
user_id=431773
I am using Windows 2000 Professional. I am not using command.com, at
least not that I know of. I'm running my program from PythonWin or IDLE
(most often the former).
Can I safely install 2.4b1 and not trash my 2.3 install? If so, I'll give
it a go.
(I know this works on Mac and unix, but have no idea how it works on
Windows).
Another possibility is to test the results at your end by editing
subprocess.py to toggle that flag that makes win32api be used instead of
_subprocess. Then launching any app using an explicit path should show the
problem (or not), since they are all in C:\\Program Files\...
--
Comment By: Peter Åstrand (astrand)
Date: 2004-10-31 07:05
Message:
Logged In: YES
user_id=344921
Are you running on Windows 9X, or using command.com?
If you are using shell=False (as in your example),
subprocess doesn't change the argument string in any way: It
is passed directly to CreateProcess.
Can you confirm that the problem only exists with Python
2.3, and not with 2.4? In that case, it might be a bug in
win32api:s CreateProcess.
--
You can re
[ python-Bugs-1607951 ] mailbox.Maildir re-reads directory too often
Bugs item #1607951, was opened at 2006-12-03 12:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox.Maildir re-reads directory too often Initial Comment: [forwarded from http://bugs.debian.org/401395] Various functions in mailbox.Maildir call self._refresh, which always re-reads the cur and new directories with os.listdir. _refresh should stat each of the two directories first to see if they changed. This cuts processing time of a series of lookups down by a factor of the number of messages in the folder, a potentially large number. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-13 08:38 Message: Logged In: YES user_id=11375 Originator: NO By stat()'ing the directories, do you mean checking the mtime? I think this isn't safe because of the limited resolution of mtime on filesystems; ext3 seems to have a 1-second resolution for mtime, for example. This means that _refresh() might read a directory, and if some other process adds or deletes a message in the same second, _refresh() couldn't detect the change. Is there some other property of directories that could be used for a more reliable check? The attached patch implements checking of mtime, but I don't recommend applying it; it causes the test suite in test_mailbox.py to break all over the place, because the process modifies mailboxes so quickly that the mtime check doesn't notice the process's own changes. I'll wait a bit for any alternative suggestion, and then close this bug as "won't fix". File Added: mailbox-mtime.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1607951&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1615275 ] tempile.TemporaryFile differences between linux and windows
Bugs item #1615275, was opened at 2006-12-13 16:20 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=1615275&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: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: hirzel (hirzel) Assigned to: Nobody/Anonymous (nobody) Summary: tempile.TemporaryFile differences between linux and windows Initial Comment: This bug came up when trying to write a numpy array to a tempfile.TemporaryFile() using the numpy 'tofile' method on windows using python 2.4. with a numpy array 'a', and a TemporaryFile 'f', on windows: >>> a.tofile(f) throws an IOError, where on Linux it does not. On windows, you must use a.tofile(f.file) The cause of this difference is that in windows, tempfile.TemporaryFile() returns that has a 'file' attribute of , whereas in linux tempfile.TemporaryFile() returns and there is no 'file' attribute. Ideally, the windows version would align with linux, and the module documentation and TemporaryFile() would return a . If this is not possible, it seems like the linux version and docs should be changed to match the windows version to align cross-platform behavior. At least, that seems to be the shared opinion of this thread from the mailing list: numpy-discussion. http://www.mail-archive.com/numpy-discussion@scipy.org/msg00271.html To my knowledge, while platform differences in tempfile have been reported in the past, this one has not. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503765 ] logger.config problems with comma separated lists
Bugs item #1503765, was opened at 2006-06-10 01:04 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&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.5 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: cuppatea (cuppatea) Assigned to: Vinay Sajip (vsajip) Summary: logger.config problems with comma separated lists Initial Comment: Hello, I have noticed a problem when trying to use the config files. If my config file contains a comma separated list, eg: [logger_root] level=DEBUG handlers= h1, h2 Then the logger throws up an error when reading in the config file as the space is included as part of the handler name. I've included a fix for this in the attached config.py file. Please feel free to use it. Hope this helps, adil -- Comment By: �iga Seilnacht (zseil) Date: 2006-12-14 00:21 Message: Logged In: YES user_id=1326842 Originator: NO Shouldn't this patch and patch #1609407 also go to the release25-maint branch? -- Comment By: Vinay Sajip (vsajip) Date: 2006-12-11 15:42 Message: Logged In: YES user_id=308438 Originator: NO Applied a modified version of this patch to SVN - trunk and release24-maint. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 08:20 Message: Logged In: YES user_id=849994 Attaching a real patch and assigning to Vinay. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1615376 ] subprocess doesn't handle SIGPIPE
Bugs item #1615376, was opened at 2006-12-14 00:21 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=1615376&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess doesn't handle SIGPIPE Initial Comment: subprocess keeps other side of child pipe open, making use of SIGPIPE to terminate writers in a pipeline not possible. This is probably a matter of documentation or providing a method to link up processes, as the parent end of the pipe must remain open until it is connected to the next process in the pipeline. An option to enable sigpipe in child would be nice. Simple example attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615376&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1611131 ] \b in unicode regex gives strange results
Bugs item #1611131, was opened at 2006-12-07 23:44 Message generated for change (Comment added) made by akaihola You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&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: Regular Expressions Group: Python 2.5 >Status: Deleted >Resolution: Invalid Priority: 5 Private: No Submitted By: akaihola (akaihola) Assigned to: Gustavo Niemeyer (niemeyer) Summary: \b in unicode regex gives strange results Initial Comment: The problem: This doesn't give a match: >>> re.match(r'ä\b', 'ä ', re.UNICODE) This works ok and gives a match: >>> re.match(r'.\b', 'ä ', re.UNICODE) Both of these work as well: >>> re.match(r'a\b', 'a ', re.UNICODE) >>> re.match(r'.\b', 'a ', re.UNICODE) Docs say \b is defined as an empty string between \w and \W. These do match accordingly: >>> re.match(r'\w', 'ä', re.UNICODE) >>> re.match(r'\w', 'a', re.UNICODE) >>> re.match(r'\W', ' ', re.UNICODE) So something strange happens in my first example, and I can't help but assume it's a bug. -- >Comment By: akaihola (akaihola) Date: 2006-12-14 02:30 Message: Logged In: YES user_id=1432932 Originator: YES Ok so this does work: >>> re.match(ur'ä\b', u'ä ', re.UNICODE) If I understand correctly, I was comparing UTF-8 encoded strings in my examples (my Ubuntu is UTF-8 by default) and regex special operators just don't work in that domain. -- Comment By: Georg Brandl (gbrandl) Date: 2006-12-08 22:51 Message: Logged In: YES user_id=849994 Originator: NO FWIW, the first example works fine for me with and without Unicode strings. -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-08 19:18 Message: Logged In: YES user_id=21627 Originator: NO Notice that the re.UNICODE flag is only meaningful if you are using Unicode strings; in the examples you give, you are using byte strings. Please re-test with Unicode strings both as the expression and as the string to match. -- Comment By: akaihola (akaihola) Date: 2006-12-08 00:18 Message: Logged In: YES user_id=1432932 Originator: YES As a work-around I currently use a regex like r'ä(?=\W)'. Seems to work ok. Also, the \b problem doesn't seem to exist in the \W\w case, i.e. at the beginning of words. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611131&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
