[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-26 16:08
Message generated for change (Comment added) made by gregcouch
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&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
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
>Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 12:21
Message:
Logged In: YES
user_id=131838
Oops, that was bug #1352621 for an analysis of why the
previous fix was bad. I closed it as a duplicate because
this bug was reopened.
The short answer to your question about schemeless URLs, is
no, they aren't supposed to work because they are not URLs.
Whether or not webbrowser.open should support filesystem
paths in addition to URLs, is a different
bug/question/patch. In my application, I encapsulate
webbrowser.open with code that supports it and it could be
added fairly easily. Here's the information needed for
anyone to do so:
Whether:
webbrowser.open("/tmp/mmhelp.html")
works or not is browser dependent (works with Netscape
4.76!). In fact, even the other example:
webbrowser.open("file:///tmp/mmhelp.html")
will fail on some browsers (Safari, may be fixed by now),
and one needs to do:
webbrowser.open("file://localhost/tmp/mmhelp.html")
instead (so a bug, but one my application had to
workaround). I recall there being cases of the reverse
being true, but I can't find those notes.
Constructing the file URL is a minor pain, but I'm not sure
what I'd change. I use urllib.pathname2url(), but that
doesn't add the file scheme. So I use urlparse.urlunparse
to build the actual URL -- that seems like overkill, but I
might have a fragment (some browsers support fragments with
the file scheme, some just ignore them). The OS X bug is
easy fix in between the calls to pathname2url and urlunparse.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-04 09:22
Message:
Logged In: YES
user_id=44345
I gave patch #1372125 a try. This still fails:
webbrowser.open("/tmp/mmhelp.html")
while this works:
webbrowser.open("file:///tmp/mmhelp.html")
Is the schemeless form supposed to work or not?
Also, there appears to be a digit missing from the bug reference #135261
and a simple search for "webbrowser" doesn't turn it up.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-02 18:12
Message:
Logged In: YES
user_id=131838
See bug #135261 and patch #1372125. The patch contains
changes to use subprocess.Popen instead of os.system for the
UnixBrowser and fixes my problems with webbrowser.py and
should address Oleg Broytmann concerns as well.
--
Comment By: Oleg Broytmann (phd)
Date: 2005-11-18 12:36
Message:
Logged In: YES
user_id=4799
So it seems the new webbrowser.py is too new. May I suggest
to rename the new module and doc to webbrowser2.py, and
restore the old version of the module and the doc?
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 20:08
Message:
Logged In: YES
user_id=44345
(Reopening. The webbrowser module still appears broken to me.)
I'm new to this thread, but webbrowser.open() in current SVN
(revision 41445) seems broken to me. This simple statement:
webbrowser.open("somefile.html")
returns True but fails to open the page in my currently running
instance of Safari. Dropping back to Python 2.4.1, it works fine.
I know webbrowser was a huge hack, but at least it appeared to do
basic stuff fine. It would appear that's no longer the case.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-09 13:43
Message:
Logged In: YES
user_id=1188172
Fixed in Revision 41419.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-10-31 14:01
Message:
Logged In: YES
user_id=131838
Breaking applications that use webbrowser does not help
application writers. It would be much more useful to me, as
an application writer, if the webbrowser module gave an
error saying it couldn't contact a web browser, rat
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-26 18:08
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&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
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 14:40
Message:
Logged In: YES
user_id=44345
> Whether or not webbrowser.open should support filesystem
> paths in addition to URLs, is a different
> bug/question/patch.
Given that it used to work, I consider it gratuitous
breakage that it doesn't anymore.
S
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 14:21
Message:
Logged In: YES
user_id=131838
Oops, that was bug #1352621 for an analysis of why the
previous fix was bad. I closed it as a duplicate because
this bug was reopened.
The short answer to your question about schemeless URLs, is
no, they aren't supposed to work because they are not URLs.
Whether or not webbrowser.open should support filesystem
paths in addition to URLs, is a different
bug/question/patch. In my application, I encapsulate
webbrowser.open with code that supports it and it could be
added fairly easily. Here's the information needed for
anyone to do so:
Whether:
webbrowser.open("/tmp/mmhelp.html")
works or not is browser dependent (works with Netscape
4.76!). In fact, even the other example:
webbrowser.open("file:///tmp/mmhelp.html")
will fail on some browsers (Safari, may be fixed by now),
and one needs to do:
webbrowser.open("file://localhost/tmp/mmhelp.html")
instead (so a bug, but one my application had to
workaround). I recall there being cases of the reverse
being true, but I can't find those notes.
Constructing the file URL is a minor pain, but I'm not sure
what I'd change. I use urllib.pathname2url(), but that
doesn't add the file scheme. So I use urlparse.urlunparse
to build the actual URL -- that seems like overkill, but I
might have a fragment (some browsers support fragments with
the file scheme, some just ignore them). The OS X bug is
easy fix in between the calls to pathname2url and urlunparse.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-04 11:22
Message:
Logged In: YES
user_id=44345
I gave patch #1372125 a try. This still fails:
webbrowser.open("/tmp/mmhelp.html")
while this works:
webbrowser.open("file:///tmp/mmhelp.html")
Is the schemeless form supposed to work or not?
Also, there appears to be a digit missing from the bug reference #135261
and a simple search for "webbrowser" doesn't turn it up.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-02 20:12
Message:
Logged In: YES
user_id=131838
See bug #135261 and patch #1372125. The patch contains
changes to use subprocess.Popen instead of os.system for the
UnixBrowser and fixes my problems with webbrowser.py and
should address Oleg Broytmann concerns as well.
--
Comment By: Oleg Broytmann (phd)
Date: 2005-11-18 14:36
Message:
Logged In: YES
user_id=4799
So it seems the new webbrowser.py is too new. May I suggest
to rename the new module and doc to webbrowser2.py, and
restore the old version of the module and the doc?
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 22:08
Message:
Logged In: YES
user_id=44345
(Reopening. The webbrowser module still appears broken to me.)
I'm new to this thread, but webbrowser.open() in current SVN
(revision 41445) seems broken to me. This simple statement:
webbrowser.open("somefile.html")
returns True but fails to open the page in my currently running
instance of Safari. Dropping back to Python 2.4.1, it works fine.
I know webbrowser was a huge hack, but at least it appeared to do
basic stuff fine. It would appear that's no longer the case.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-11-09 15:43
Message:
Logged In: YES
user_id=1188172
Fixed in Revision 41419.
---
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-26 16:08
Message generated for change (Comment added) made by gregcouch
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&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
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
>Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 13:21
Message:
Logged In: YES
user_id=131838
Then file a bug report with whoever makes your web browser.
It's not Python's webbrowser module's fault that the
browser doesn't accept filesystem paths. The webbrowser
module is only documented to work with URLs, so any code
that depends on paths is arguably buggy. That said, if
someone else will write a patch for the documentation, I
will write a patch for the code. - Greg
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 12:40
Message:
Logged In: YES
user_id=44345
> Whether or not webbrowser.open should support filesystem
> paths in addition to URLs, is a different
> bug/question/patch.
Given that it used to work, I consider it gratuitous
breakage that it doesn't anymore.
S
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 12:21
Message:
Logged In: YES
user_id=131838
Oops, that was bug #1352621 for an analysis of why the
previous fix was bad. I closed it as a duplicate because
this bug was reopened.
The short answer to your question about schemeless URLs, is
no, they aren't supposed to work because they are not URLs.
Whether or not webbrowser.open should support filesystem
paths in addition to URLs, is a different
bug/question/patch. In my application, I encapsulate
webbrowser.open with code that supports it and it could be
added fairly easily. Here's the information needed for
anyone to do so:
Whether:
webbrowser.open("/tmp/mmhelp.html")
works or not is browser dependent (works with Netscape
4.76!). In fact, even the other example:
webbrowser.open("file:///tmp/mmhelp.html")
will fail on some browsers (Safari, may be fixed by now),
and one needs to do:
webbrowser.open("file://localhost/tmp/mmhelp.html")
instead (so a bug, but one my application had to
workaround). I recall there being cases of the reverse
being true, but I can't find those notes.
Constructing the file URL is a minor pain, but I'm not sure
what I'd change. I use urllib.pathname2url(), but that
doesn't add the file scheme. So I use urlparse.urlunparse
to build the actual URL -- that seems like overkill, but I
might have a fragment (some browsers support fragments with
the file scheme, some just ignore them). The OS X bug is
easy fix in between the calls to pathname2url and urlunparse.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-04 09:22
Message:
Logged In: YES
user_id=44345
I gave patch #1372125 a try. This still fails:
webbrowser.open("/tmp/mmhelp.html")
while this works:
webbrowser.open("file:///tmp/mmhelp.html")
Is the schemeless form supposed to work or not?
Also, there appears to be a digit missing from the bug reference #135261
and a simple search for "webbrowser" doesn't turn it up.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-02 18:12
Message:
Logged In: YES
user_id=131838
See bug #135261 and patch #1372125. The patch contains
changes to use subprocess.Popen instead of os.system for the
UnixBrowser and fixes my problems with webbrowser.py and
should address Oleg Broytmann concerns as well.
--
Comment By: Oleg Broytmann (phd)
Date: 2005-11-18 12:36
Message:
Logged In: YES
user_id=4799
So it seems the new webbrowser.py is too new. May I suggest
to rename the new module and doc to webbrowser2.py, and
restore the old version of the module and the doc?
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-11-14 20:08
Message:
Logged In: YES
user_id=44345
(Reopening. The webbrowser module still appears broken to me.)
I'm new to this thread, but webbrowser.open() in current SVN
(revision 41445) se
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-26 18:08
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&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
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 15:57
Message:
Logged In: YES
user_id=44345
You're missing the point. It works in Python 2.4 and
doesn't on CVS HEAD. I've already had to modify one
application. Maybe the old webbrowser module
used to prepend a "file://localhost/" to filenames
that were missing schemes. All I know is it used to
work and now it doesn't As is, 2.5 is likely to
break some applications that rely on the behavior in
2.4.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 15:21
Message:
Logged In: YES
user_id=131838
Then file a bug report with whoever makes your web browser.
It's not Python's webbrowser module's fault that the
browser doesn't accept filesystem paths. The webbrowser
module is only documented to work with URLs, so any code
that depends on paths is arguably buggy. That said, if
someone else will write a patch for the documentation, I
will write a patch for the code. - Greg
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 14:40
Message:
Logged In: YES
user_id=44345
> Whether or not webbrowser.open should support filesystem
> paths in addition to URLs, is a different
> bug/question/patch.
Given that it used to work, I consider it gratuitous
breakage that it doesn't anymore.
S
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 14:21
Message:
Logged In: YES
user_id=131838
Oops, that was bug #1352621 for an analysis of why the
previous fix was bad. I closed it as a duplicate because
this bug was reopened.
The short answer to your question about schemeless URLs, is
no, they aren't supposed to work because they are not URLs.
Whether or not webbrowser.open should support filesystem
paths in addition to URLs, is a different
bug/question/patch. In my application, I encapsulate
webbrowser.open with code that supports it and it could be
added fairly easily. Here's the information needed for
anyone to do so:
Whether:
webbrowser.open("/tmp/mmhelp.html")
works or not is browser dependent (works with Netscape
4.76!). In fact, even the other example:
webbrowser.open("file:///tmp/mmhelp.html")
will fail on some browsers (Safari, may be fixed by now),
and one needs to do:
webbrowser.open("file://localhost/tmp/mmhelp.html")
instead (so a bug, but one my application had to
workaround). I recall there being cases of the reverse
being true, but I can't find those notes.
Constructing the file URL is a minor pain, but I'm not sure
what I'd change. I use urllib.pathname2url(), but that
doesn't add the file scheme. So I use urlparse.urlunparse
to build the actual URL -- that seems like overkill, but I
might have a fragment (some browsers support fragments with
the file scheme, some just ignore them). The OS X bug is
easy fix in between the calls to pathname2url and urlunparse.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-04 11:22
Message:
Logged In: YES
user_id=44345
I gave patch #1372125 a try. This still fails:
webbrowser.open("/tmp/mmhelp.html")
while this works:
webbrowser.open("file:///tmp/mmhelp.html")
Is the schemeless form supposed to work or not?
Also, there appears to be a digit missing from the bug reference #135261
and a simple search for "webbrowser" doesn't turn it up.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-02 20:12
Message:
Logged In: YES
user_id=131838
See bug #135261 and patch #1372125. The patch contains
changes to use subprocess.Popen instead of os.system for the
UnixBrowser and fixes my problems with webbrowser.py and
should address Oleg Broytmann concerns as well.
--
Comment By: Oleg Broytmann (phd)
Date: 2005-
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-26 16:08
Message generated for change (Comment added) made by gregcouch
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&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
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
>Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 14:27
Message:
Logged In: YES
user_id=131838
And you seem to have scanned my previous post and missed
where I discussed all of the problems with
webbrowser.open(path). I should have been more explicit
that those were problems with the all versions of the
webbrowser module. It is browser-dependent whether or not
opening a path works at all. I have had to work around that
"problem" for years (starting with grail in 1997 and carried
over to the webbroswer module in 2001). Any cross-platform
developer, that tests their code, already has a workaround
in place.
If the webbrowser documentation agreed with you, then I
would agree with you as well. Although I feel we are
already violently agreeing. "Fix" the documentation and
I'll "fix" the code.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 13:57
Message:
Logged In: YES
user_id=44345
You're missing the point. It works in Python 2.4 and
doesn't on CVS HEAD. I've already had to modify one
application. Maybe the old webbrowser module
used to prepend a "file://localhost/" to filenames
that were missing schemes. All I know is it used to
work and now it doesn't As is, 2.5 is likely to
break some applications that rely on the behavior in
2.4.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 13:21
Message:
Logged In: YES
user_id=131838
Then file a bug report with whoever makes your web browser.
It's not Python's webbrowser module's fault that the
browser doesn't accept filesystem paths. The webbrowser
module is only documented to work with URLs, so any code
that depends on paths is arguably buggy. That said, if
someone else will write a patch for the documentation, I
will write a patch for the code. - Greg
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 12:40
Message:
Logged In: YES
user_id=44345
> Whether or not webbrowser.open should support filesystem
> paths in addition to URLs, is a different
> bug/question/patch.
Given that it used to work, I consider it gratuitous
breakage that it doesn't anymore.
S
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 12:21
Message:
Logged In: YES
user_id=131838
Oops, that was bug #1352621 for an analysis of why the
previous fix was bad. I closed it as a duplicate because
this bug was reopened.
The short answer to your question about schemeless URLs, is
no, they aren't supposed to work because they are not URLs.
Whether or not webbrowser.open should support filesystem
paths in addition to URLs, is a different
bug/question/patch. In my application, I encapsulate
webbrowser.open with code that supports it and it could be
added fairly easily. Here's the information needed for
anyone to do so:
Whether:
webbrowser.open("/tmp/mmhelp.html")
works or not is browser dependent (works with Netscape
4.76!). In fact, even the other example:
webbrowser.open("file:///tmp/mmhelp.html")
will fail on some browsers (Safari, may be fixed by now),
and one needs to do:
webbrowser.open("file://localhost/tmp/mmhelp.html")
instead (so a bug, but one my application had to
workaround). I recall there being cases of the reverse
being true, but I can't find those notes.
Constructing the file URL is a minor pain, but I'm not sure
what I'd change. I use urllib.pathname2url(), but that
doesn't add the file scheme. So I use urlparse.urlunparse
to build the actual URL -- that seems like overkill, but I
might have a fragment (some browsers support fragments with
the file scheme, some just ignore them). The OS X bug is
easy fix in between the calls to pathname2url and urlunparse.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-04 09:22
Messag
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-26 18:08
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&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
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 17:38
Message:
Logged In: YES
user_id=44345
All I'm saying is that if this form
webbrowser.open("/tmp/foo.html")
was supported in Python 2.4, possibly by recognizing the bare
path and silently pretending the programmer wrote
webbrowser.open("file://localhost/tmp/foo.html")
then it ought to do the same in 2.5 unless you intend to break
existing applications. How hard can it be to recognize that
the first character of the "url" is "/" and prepend "file://localhost/"
before passing it along to the user's chosen browser?
I suggest compatibility with urllib.urlopen is desirable:
>>> f = urllib.urlopen("/etc/hosts")
>>> f.read()
"##\n# Host Database\n# \n# Note that this file is consulted when the
system is running in single-user\n# mode. At other times this information is
handled by lookupd. By default,\n# lookupd gets information from NetInfo,
so this file will not be consulted\n# unless you have changed lookupd's
configuration.\n#\n# localhost is used to configure the loopback interface\n#
when the system is booting. Do not change this
entry.\n##\n127.0.0.1\tlocalhost
montanaro.dyndns.org\n255.255.255.255\tbroadcasthost\n"
Skip
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 16:27
Message:
Logged In: YES
user_id=131838
And you seem to have scanned my previous post and missed
where I discussed all of the problems with
webbrowser.open(path). I should have been more explicit
that those were problems with the all versions of the
webbrowser module. It is browser-dependent whether or not
opening a path works at all. I have had to work around that
"problem" for years (starting with grail in 1997 and carried
over to the webbroswer module in 2001). Any cross-platform
developer, that tests their code, already has a workaround
in place.
If the webbrowser documentation agreed with you, then I
would agree with you as well. Although I feel we are
already violently agreeing. "Fix" the documentation and
I'll "fix" the code.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 15:57
Message:
Logged In: YES
user_id=44345
You're missing the point. It works in Python 2.4 and
doesn't on CVS HEAD. I've already had to modify one
application. Maybe the old webbrowser module
used to prepend a "file://localhost/" to filenames
that were missing schemes. All I know is it used to
work and now it doesn't As is, 2.5 is likely to
break some applications that rely on the behavior in
2.4.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 15:21
Message:
Logged In: YES
user_id=131838
Then file a bug report with whoever makes your web browser.
It's not Python's webbrowser module's fault that the
browser doesn't accept filesystem paths. The webbrowser
module is only documented to work with URLs, so any code
that depends on paths is arguably buggy. That said, if
someone else will write a patch for the documentation, I
will write a patch for the code. - Greg
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 14:40
Message:
Logged In: YES
user_id=44345
> Whether or not webbrowser.open should support filesystem
> paths in addition to URLs, is a different
> bug/question/patch.
Given that it used to work, I consider it gratuitous
breakage that it doesn't anymore.
S
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 14:21
Message:
Logged In: YES
user_id=131838
Oops, that was bug #1352621 for an analysis of why the
previous fix was bad. I closed it as a duplicate because
this bug was reopened.
The short answer to your question about schemeless URLs, is
no, they aren't supposed to work because they are not URLs.
Whether or not webbrowse
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-26 16:08
Message generated for change (Comment added) made by gregcouch
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&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
Submitted By: Greg Couch (gregcouch)
Assigned to: Nobody/Anonymous (nobody)
Summary: CVS webbrowser.py (1.40) bugs
Initial Comment:
There are two calls to _safequote that are only made on
darwin, aka, Mac OS X. That function is missing.
And the UnixBrowser is missing an & in the "simpler
command" and thus causes python to hang until the
browser is exited (if it wasn't running already).
--
>Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 16:13
Message:
Logged In: YES
user_id=131838
And I agree it is desirable, but it didn't work reliably in
2.4 nor any earlier version, and it isn't documented to work.
The urllib.urlopen example you gave fails miserably with
Windows files names, i.e., given "C:\WINDOWS\system.ini" it
tries to interpret the C as a scheme. You need to use
urllib's pathname2url function and pass the result to
urlopen. If webbrowser.open is fixed, then maybe there will
be some pressure to fix urlopen as well.
You just have been lucky or unlucky depending on how you
view it.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 15:38
Message:
Logged In: YES
user_id=44345
All I'm saying is that if this form
webbrowser.open("/tmp/foo.html")
was supported in Python 2.4, possibly by recognizing the bare
path and silently pretending the programmer wrote
webbrowser.open("file://localhost/tmp/foo.html")
then it ought to do the same in 2.5 unless you intend to break
existing applications. How hard can it be to recognize that
the first character of the "url" is "/" and prepend "file://localhost/"
before passing it along to the user's chosen browser?
I suggest compatibility with urllib.urlopen is desirable:
>>> f = urllib.urlopen("/etc/hosts")
>>> f.read()
"##\n# Host Database\n# \n# Note that this file is consulted when the
system is running in single-user\n# mode. At other times this information is
handled by lookupd. By default,\n# lookupd gets information from NetInfo,
so this file will not be consulted\n# unless you have changed lookupd's
configuration.\n#\n# localhost is used to configure the loopback interface\n#
when the system is booting. Do not change this
entry.\n##\n127.0.0.1\tlocalhost
montanaro.dyndns.org\n255.255.255.255\tbroadcasthost\n"
Skip
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 14:27
Message:
Logged In: YES
user_id=131838
And you seem to have scanned my previous post and missed
where I discussed all of the problems with
webbrowser.open(path). I should have been more explicit
that those were problems with the all versions of the
webbrowser module. It is browser-dependent whether or not
opening a path works at all. I have had to work around that
"problem" for years (starting with grail in 1997 and carried
over to the webbroswer module in 2001). Any cross-platform
developer, that tests their code, already has a workaround
in place.
If the webbrowser documentation agreed with you, then I
would agree with you as well. Although I feel we are
already violently agreeing. "Fix" the documentation and
I'll "fix" the code.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 13:57
Message:
Logged In: YES
user_id=44345
You're missing the point. It works in Python 2.4 and
doesn't on CVS HEAD. I've already had to modify one
application. Maybe the old webbrowser module
used to prepend a "file://localhost/" to filenames
that were missing schemes. All I know is it used to
work and now it doesn't As is, 2.5 is likely to
break some applications that rely on the behavior in
2.4.
--
Comment By: Greg Couch (gregcouch)
Date: 2005-12-06 13:21
Message:
Logged In: YES
user_id=131838
Then file a bug report with whoever makes your web browser.
It's not Python's webbrowser module's fault that the
browser doesn't accept filesystem paths. The webbrowser
module is only documented to work with URLs, so any code
that depends on paths is arguably buggy. That said, if
someone else will write a patch for the documentation, I
will write a patch for the code. - Greg
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-12-06 12:40
Message:
Logged In:
