[ python-Bugs-687747 ] _iscommand() in webbrowser module
SourceForge.net
noreply at sourceforge.net
Sun Sep 4 02:36:52 CEST 2005
Bugs item #687747, was opened at 2003-02-17 07:17
Message generated for change (Comment added) made by ekid
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&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: 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: Dmitry Vukolov (ekid)
Date: 2005-09-04 04:36
Message:
Logged In: YES
user_id=1000960
The problem still exists in Python 2.4.1
----------------------------------------------------------------------
Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 23:37
Message:
Logged In: YES
user_id=752496
richard seems to reproduced it on Py2.3, changing the group
to it.
----------------------------------------------------------------------
Comment By: Richard Jones (richard)
Date: 2005-01-17 01: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.py 2005-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 15: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 04: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.000000000 +1000
+++ /usr/lib/python2.3/webbrowser.py 2003-08-04
10:18:17.000000000 +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 04: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-02 23:43
Message:
Logged In: YES
user_id=198518
A week after posting <slrnb5iu1s.t8.matt at sake.mondoinfo.com>
("webbrowser module under MacOS"), it hasn't gotten any
replies. That suggests that Mac users either don't much care
about the module or don't read comp.lang.python.
If it's desirable merely to stop at the first space, it
should be sufficient to replace:
if _iscommand(cmd.lower()):
with
if _iscommand(cmd.lower().split(" ")[0]):
There remain some things that are dubious about the handling
of the values in the BROWSER environment variable. In
particular, the lower() in that line, the assumption that
the executables specified in BROWSER are in the user's PATH,
and the lack of handling of %% and %s in those values.
Still, it may be reasonable to ignore those issues until
they pose a problem.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-23 16:53
Message:
Logged In: YES
user_id=6380
Please ask around on c.l.py if the macintosh problem
actually exists; if it doesn't, stopping at the first space
sounds like the right idea.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470
More information about the Python-bugs-list
mailing list