[ python-Bugs-711830 ] SEEK_{SET,CUR,END} missing in 2.2.2
Bugs item #711830, was opened at 2003-03-29 16:54
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470
Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: SEEK_{SET,CUR,END} missing in 2.2.2
Initial Comment:
Python 1.5.2 used to define SEEK_{SET,CUR,END} both in
FCNTL.py and in posixfile.py
Python 2.2.2 obsoletes both of them (and the symbols
are no longer in FCNTL anyway).
A quick grep on the 2.2.2 tree shows me posixfile is
the only place that still defines the SEEK_* constants.
It seems to me it's wrong to drop the constants
(because a deprecated module will eventually be dropped).
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-01-16 09:41
Message:
Logged In: YES
user_id=21627
This is now fixed in
os.py 1.84
libos.tex 1.149
NEWS 1.1226
--
Comment By: Mihai Ibanescu (misa)
Date: 2005-01-16 04:39
Message:
Logged In: YES
user_id=205865
Did a quick grep in python 2.3.4 - still only defined in
posixfile which is deprecated.
I didn't notice Martin's question - yes, the os module seems
to be the best place to put them.
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 18:43
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 18:36
Message:
Logged In: YES
user_id=21627
Would you agree that these constants are best located in the
os module?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711830&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-774546 ] popen does not like filenames with spaces
Feature Requests item #774546, was opened at 2003-07-20 14:29 Message generated for change (Comment added) made by pfremy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=774546&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: popen does not like filenames with spaces Initial Comment: The argument for the target executable are passed as a string to popen. The problem is that with filenames which contains spaces, the argument breaking routine will fail and create two arguments for one filename. It would be more convenient if one could pass the argument to popen as a list of string. -- >Comment By: Philippe Fremy (pfremy) Date: 2005-01-16 11:43 Message: Logged In: YES user_id=233844 I am ok with closing the bug as WONTFIX but I think that: - the documentation to os.popen and the module popen should inform the user about this limitation - the documentatino to os.popen and the module popen should point the user to the new subprocess module Not everybody reads the What's new and people might still be using popen when subprocess does a better job. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-16 02:00 Message: Logged In: YES user_id=80475 The proposed change would not be eligible for backporting as it is a new feature. And since Py2.4 and later already have a preferred solution (in the form of the subprocess modules), will close this feature request as being out-of-date (or least, no longer necessary). Feel free to re-open if the sub-process module does not fully meet your needs. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 20:46 Message: Logged In: YES user_id=752496 Think that this should be closed with "Won't fix" specially now that we have the subprocess module. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 20:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Peter Åstrand (astrand) Date: 2003-11-01 17:44 Message: Logged In: YES user_id=344921 popen5 (http://www.lysator.liu.se/~astrand/popen5/) uses a sequence argument instead of a string, and has no problems with whitespace. Also, it supports connecting several subprocesses together (feeding the output from one command into another). -- Comment By: Philippe Fremy (pfremy) Date: 2003-09-01 12:41 Message: Logged In: YES user_id=233844 I was trying to use python as a shell replacement for simple scripts, but I was disapppointed by the poor level of support of python for those things. In my case, the list of files was pulled from a command and passed to another one. I have some suggestions on how to improve python shell scripting capability. Right now, as soon as you want to do something a little bit complicated, like feeding a program (let's say grep) from the output of another program and checking the output and the exit status is quite complicated. For such an interface to be good, it has to provide _very_ easy way to: - read stdout from a command - provide stdin to a command - read exit status of a command. - pipe a command into another one Let's say I want to run the equivalent of find . -name '*.cpp' | grep -i toto My suggested interface to run a simple command would be as following: cmd( "find", ".", "-name", "*.cpp") This defines a command to be run. To be versatile, this would have to accept although the following format: cmd( [ "find", ".", "-name", "*.cpp" ] ) cmd( "find", [ ".", "-name", "*.cpp" ] ) which are slightly different ways of spawning a command. I think all these three ways have a usage pattern. To actually execute the command, you woud do: cmd( "find", ".", "-name", "*.cpp" ).go() This create an object which has To run it, you just apply the go() method: cmd( "find", ".", "*.cpp" ).go() This could return a tuple (stdout, stderr, return_code) Now, if you want to pipe a command into another one, we can either override the operator | or write it manually. My initial command would become: cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ) I dislike using a syntax like cmd().pipe( c
[ python-Bugs-1103350 ] send/recv SEGMENT_SIZE should be used more in socketmodule
Bugs item #1103350, was opened at 2005-01-16 16:01 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=1103350&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: send/recv SEGMENT_SIZE should be used more in socketmodule Initial Comment: socketmodule.c contains a SEGMENT_SIZE define that is used to limit the send/recv buffer size on VMS. But IMO there are two problems: 1) it should also be used on windows, because windows doesn't like a large send/recv buffer either, 2) it should be used in more places: at least sendall, but perhaps also recvfrom, sendto ad 1: see also this bug: http://www.python.org/sf/853507 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103350&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1102649 ] pickle files should be opened in binary mode
Bugs item #1102649, was opened at 2005-01-14 22:58 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Machin (sjmachin) Assigned to: Nobody/Anonymous (nobody) Summary: pickle files should be opened in binary mode Initial Comment: pickle (and cPickle): At _each_ mention of the pickle file, the docs should say that it should be opened with 'wb' or 'rb' mode as appropriate, so that a pickle written on one OS can be read reliably on another. The example code at the end of the section should be updated to use the 'b' flag. -- Comment By: Irmen de Jong (irmen) Date: 2005-01-16 16:07 Message: Logged In: YES user_id=129426 Can't the pickle code just freopen() the file itself, using binary mode? Or is this against Python's rule "explicit is better than implicit" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1102649&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs
Bugs item #737202, was opened at 2003-05-13 19:54
Message generated for change (Comment added) made by htgoebel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Hartmut Goebel (htgoebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer does not handle scripts in sub-dirs
Initial Comment:
CGIHTTPServer does not handle scripts in sub directoreis correctly:
When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns
404 CGI script is not a plain file ('/cgi-bin/script')
This tracked down to CGIHTTPRequestHandler.run_cgi() containing
these lines:
i = rest.find('/')
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
This will move the dir-part of the 'rest' into 'script', but leave the
actual filename in 'rest'. The 'scriptname' thus does miss the filename.
I assume this should become simply:
script, rest = rest, ''
scriptname = dir + '/' + script
--
>Comment By: Hartmut Goebel (htgoebel)
Date: 2005-01-16 16:11
Message:
Logged In: YES
user_id=376953
Encloded please find a testcase.
I've checkt it with 2.3.3.
Buf should still persist in 2.3.4 and 2.4. I've checked the
CVS diffs and there is no change which would solve it.
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 19:42
Message:
Logged In: YES
user_id=752496
Both bugs are for the same problem, keeping this alive
(because it has the patch), closing the other as Duplicate.
Regarding the patch, the actual code has something very
similar to it, so maybe the bug is already fixed...
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 19:42
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Titus Brown (titus)
Date: 2004-12-19 07:20
Message:
Logged In: YES
user_id=23486
same as bug 778804, assigned to esr.
--
Comment By: Hartmut Goebel (htgoebel)
Date: 2003-05-23 15:21
Message:
Logged In: YES
user_id=376953
I rethought this: The reason for this type of split is to make it possible to
pass parameters as part of the URL, like Zope does.
So the snippet above should be changed to something like this:
i = 0
while 1:
# get the next path-element out of the url
i = rest.find('/', i)
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
scriptfile = self.translatepath(scriptname)
if os.isdir(scriptname):
# if scriptname is a directory, continue "walking" the url
continue
# scriptname is not a directory, stop "walking" the url
break
Patch is included.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1100429 ] TarFile iteration can break (on Windows) if file has links
Bugs item #1100429, was opened at 2005-01-11 21:54 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100429&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: TarFile iteration can break (on Windows) if file has links Initial Comment: I ran into this with a simple loop trying to detar Pyrex-0.9.3: for info in tarfile: tarfile.extract(info) I called the above immediately after calling tarfile.open, so the returned iterator was an instance of TarIter. The problem is that Pyrex includes some symbolic links. When TarFile.makelink finds that os.symlink is missing (on Windows) it then does getmember to find the info for the referenced file. The getmember method results in a call to getmembers, which loads all the infos into the members list. However, this breaks the TarIter, since it assumes the members have not yet been loaded. Not sure what the best fix for this is; in my script, I switched over to using getmembers rather than the iterator. -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-01-16 18:40 Message: Logged In: YES user_id=642936 I wrote a patch (#1103407) that should fix this. Thank you for pointing that out. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-687747 ] _iscommand() in webbrowser module
Bugs item #687747, was opened at 2003-02-17 15:17
Message generated for change (Comment added) made by richard
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: _iscommand() in webbrowser module
Initial Comment:
[From a post to python-help]
Under KDE under Mandrake Linux the BROWSER environment
variable is set to
kfmclient openProfile webbrowsing
The problem is that _iscommand() in the webbrowser
module doesn't realize that only the first thing there
is the name of the executable. It looks for an
executable with that whole thing as its name and
doesn't find one. Since the module doesn't use any
browser it has found if BROWSER is set, it raises an
error rather than opening the page.
The possible fixes that are obvious to me all have
potential disadvantages:
One solution would be to assume that the name of the
executable ran only up to the first space. But
executables can have spaces in their names, especially
on a Macintosh, I think.
Another possibility would be not to call _iscommand()
on anything in BROWSER. That would have the additional
advantage of not requiring that the executable
specified there be in a directory that's in the user's
PATH. The problem with doing things this way is that it
would be impossible to tell which of the browsers
specified in BROWSER should be used until the user
called open().
I'm prepared to work on a fix if given some guidance
about the best way to go.
--
Comment By: Richard Jones (richard)
Date: 2005-01-17 09:01
Message:
Logged In: YES
user_id=6405
This is still an issue.
python -c 'import
webbrowser;webbrowser.open("http://www.google.com/";)'
on a system using KDE will exhibit the break.
I posted a patch to fix the behaviour in my last message. I just
noticed that I invoked diff the wrong way around (though the
explanation still stands) - a correct invocation:
--- /tmp/webbrowser.py 2005-01-17 08:59:50.697657208
+1100
+++ /usr/lib/python2.3/webbrowser.py2005-01-17
08:59:58.269989095 +1100
@@ -354,7 +354,7 @@
if "BROWSER" in os.environ:
# It's the user's responsibility to register handlers for any
unknown
# browser referenced by this value, before calling open().
-_tryorder = os.environ["BROWSER"].split(os.pathsep)
+_tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep)
for cmd in _tryorder:
if not cmd.lower() in _browsers:
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 23:26
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Richard Jones (richard)
Date: 2003-08-20 10:29
Message:
Logged In: YES
user_id=6405
This is still an issue... has there been any movement on it outside of this
bug report?
I'm seeing the behaviour on Mandrake 9.1, KDE 3.1.3 that the module is
finding the BROWSER env var as described above, and thus not finding a
usable browser.
As a fallback, the _tryorder shouldn't be *replaced* by BROWSER, but
just prepended with its value. Sure, that means that the KDE BROWSER
value will be ignored, but it'll still find konqueror. This approach works for
me, and I'm sure it'll work for others who have "valid" BROWSER
values
:)
Simple patch against python2.3 (sorry, sf will mangle this, but it's short):
--- webbrowser.py 2003-08-20 10:28:07.0 +1000
+++ /usr/lib/python2.3/webbrowser.py2003-08-04
10:18:17.0 +1000
@@ -354,7 +354,7 @@
if "BROWSER" in os.environ:
# It's the user's responsibility to register handlers for any unknown
# browser referenced by this value, before calling open().
-_tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep)
+_tryorder = os.environ["BROWSER"].split(os.pathsep)
for cmd in _tryorder:
if not cmd.lower() in _browsers:
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-03 12:19
Message:
Logged In: YES
user_id=6380
You know, I have no idea why all the lower() business is
there. Assigning to Fred Drake, maybe he knows more. (Fred,
please treat this as a hot potato -- if you don't
immediately know the answer, assign it back to me.)
--
Comment By: Matthew Cowles (mdcowles)
Date: 2003-03-
[ python-Bugs-702147 ] --without-cxx flag of configure isn't documented.
Bugs item #702147, was opened at 2003-03-12 04:05 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702147&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: J.A. Schonekerl (jschonek2) Assigned to: Nobody/Anonymous (nobody) Summary: --without-cxx flag of configure isn't documented. Initial Comment: Hi, I can't any discription of the --without-cxx for configure. If you do a ./configure --help it simply doesn't show up! And let this be the flag I needed to build python without libstdc++! Best regards, Jan -- >Comment By: Brett Cannon (bcannon) Date: 2005-01-16 16:26 Message: Logged In: YES user_id=357491 This is no longer a problem. Closed as "out of date". -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 04:53 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Martin v. Löwis (loewis) Date: 2003-03-17 14:14 Message: Logged In: YES user_id=21627 Yes, please attached unified or context diffs to this bug report, preferably using the CVS version of Python (or 2.3a2 if CVS is not possible). -- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 11:30 Message: Logged In: YES user_id=732192 It becomes clear for me that making a good help for all systems out there is very difficult. But I could create a better ./configure --help output for python that is comon for all systems. And I can create a patch for the README file that explains the libstdc++ dependencies if you are building with GNU C++. Can I simply add a patch for these to the patch list or how does it work? -- Comment By: Martin v. Löwis (loewis) Date: 2003-03-17 10:39 Message: Logged In: YES user_id=21627 Being a C++ expert won't help you in explaining libstdc++ dependencies: This is specific to GNU C++, not to C++ in general. So you need to be an expert of your operating system; to some degree, this is expected from somebody building software on a system. I *think* that configure --help lists not the defaults, but the non-defaults in most cases, i.e. the options that you need to pass. In some cases (e.g. --with-cxx=), they are not really booleans, but, if activated, also support a parameter (the name of the C++ compiler, for --with-cxx). In that case, the default is more involved: If not specified, --with-cxx is assumed if a C++ compiler can be found and if linking with that C++ compiler is necessary on your system (some systems support C++ extension but don't require Python to be linked with the C++ compiler). So, please do propose specific wording. I think there is little point in explaining every detail of what exactly the configuration tries in what circumstance; so maybe something general enough that still would have helped you might be appropriate. -- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 04:24 Message: Logged In: YES user_id=732192 For example.. The postgresql configure help does it better: Optional Packages: --with-PACKAGE[=ARG]use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] It also adds: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -Lif you have libraries in a nonstandard directory CPPFLAGSC/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory CPP C preprocessor DOCBOOKSTYLE location of DocBook stylesheets But if all listed "oiptional pakages" and "optional features" are the default isn't clear in this configure output either. The Python configure needs a general face-lift. -- Comment By: J.A. Schonekerl (jschonek2) Date: 2003-03-17 03:49 Message: Logged In: YES user_id=732192 For me it wasn't clear why the libstdc++ library was dynamicaly linked into the python interpreter. I could not find th
[ python-Bugs-1090139 ] presentation typo in lib: 6.21.4.2 How callbacks are called
Bugs item #1090139, was opened at 2004-12-22 20:00 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jesse Weinstein (weinsteinj) Assigned to: Greg Ward (gward) Summary: presentation typo in lib: 6.21.4.2 How callbacks are called Initial Comment: On the page: http://docs.python.org/lib/optparse-how-callbacks-called.html the text: args should be changed to: args to match the rest of the items on the page. This may require changing the LaTeX. -- >Comment By: Greg Ward (gward) Date: 2005-01-16 21:30 Message: Logged In: YES user_id=14422 This problem stems from the mkpydoc script in Optik's source repository. I've fixed it there (rev 485) so that future merges from Optik's repository into Python's won't resurrect this bug. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-31 04:35 Message: Logged In: YES user_id=469548 I think the optparse documentation is automatically generated from the optik ReST docs, so Greg should take a look at this as well. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-30 20:08 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs
Bugs item #737202, was opened at 2003-05-13 10:54
Message generated for change (Comment added) made by titus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470
Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Hartmut Goebel (htgoebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer does not handle scripts in sub-dirs
Initial Comment:
CGIHTTPServer does not handle scripts in sub directoreis correctly:
When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns
404 CGI script is not a plain file ('/cgi-bin/script')
This tracked down to CGIHTTPRequestHandler.run_cgi() containing
these lines:
i = rest.find('/')
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
This will move the dir-part of the 'rest' into 'script', but leave the
actual filename in 'rest'. The 'scriptname' thus does miss the filename.
I assume this should become simply:
script, rest = rest, ''
scriptname = dir + '/' + script
--
Comment By: Titus Brown (titus)
Date: 2005-01-16 21:31
Message:
Logged In: YES
user_id=23486
Verified proper behavior does not work in 2.2, 2.3, 2.4, or current CVS.
The attached patches are just a filename; you should try downloading
them to be sure they're actually a patch ;).
A simpe self-contained example is at
http://issola.caltech.edu/~t/transfer/python-bug737202-example.tgz
it works under Python 2.2 or greater & demonstrates the problem.
A patch for the current CVS HEAD is at
http://issola.caltech.edu/~t/transfer/python-bug737202-patch.diff
and 2.4 should probably be back-patched as well.
--
Comment By: Hartmut Goebel (htgoebel)
Date: 2005-01-16 07:11
Message:
Logged In: YES
user_id=376953
Encloded please find a testcase.
I've checkt it with 2.3.3.
Buf should still persist in 2.3.4 and 2.4. I've checked the
CVS diffs and there is no change which would solve it.
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 10:42
Message:
Logged In: YES
user_id=752496
Both bugs are for the same problem, keeping this alive
(because it has the patch), closing the other as Duplicate.
Regarding the patch, the actual code has something very
similar to it, so maybe the bug is already fixed...
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 10:42
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Titus Brown (titus)
Date: 2004-12-18 22:20
Message:
Logged In: YES
user_id=23486
same as bug 778804, assigned to esr.
--
Comment By: Hartmut Goebel (htgoebel)
Date: 2003-05-23 06:21
Message:
Logged In: YES
user_id=376953
I rethought this: The reason for this type of split is to make it possible to
pass parameters as part of the URL, like Zope does.
So the snippet above should be changed to something like this:
i = 0
while 1:
# get the next path-element out of the url
i = rest.find('/', i)
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
scriptname = dir + '/' + script
scriptfile = self.translatepath(scriptname)
if os.isdir(scriptname):
# if scriptname is a directory, continue "walking" the url
continue
# scriptname is not a directory, stop "walking" the url
break
Patch is included.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
