Bugs item #687747, was opened at 2003-02-17 05:17 Message generated for change (Comment added) made by birkenfeld 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: Closed >Resolution: Fixed 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: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 09:51 Message: Logged In: YES user_id=1188172 Corrected in webbrowser.py r1.37.4.1. For the 2.5 branch, a new patch will be checked in which corrects this too. ---------------------------------------------------------------------- Comment By: Dmitry Vukolov (ekid) Date: 2005-09-04 02: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 21: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-16 23: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 13: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 02: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 02: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 21:43 Message: Logged In: YES user_id=198518 A week after posting <[EMAIL PROTECTED]> ("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 14: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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com