webbrowser.py: browser >/dev/null 2>&1
Hello! While I'm working on webbrowser... Why do all graphical browsers are called with their stdout/stderr redirected to /dev/null? Do we really need to hide problems from the user? Browsers are usually silent beasts - they interact with the user using windows, not stdio. (Text-mode browsers, naturally, use stdout... for their windows). I'd like to remove all those redirects. Any opinion? Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Wed, 23 Mar 2005 15:40:20 +0300
Oleg Broytmann
Hello!
While I'm working on webbrowser...
Great.
Why do all graphical browsers are called with their stdout/stderr redirected to /dev/null?
Under some linux distros (I'm positive for some Mdk releases), Mozilla is compiled dumping a lot of info to stdout/stderr. Since one of the goals of webbrowser is to give the end-user a stress-free experience, there goes the mentioned nullification <wink>. In a development environment, a developer should not find difficulty to reverse that if needed.
I'd like to remove all those redirects. Any opinion? -1 for me.
best regards, Rod Senra
On Wed, Mar 23, 2005 at 10:25:12AM -0300, Rodrigo Dias Arruda Senra wrote:
Why do all graphical browsers are called with their stdout/stderr redirected to /dev/null?
Under some linux distros (I'm positive for some Mdk releases), Mozilla is compiled dumping a lot of info to stdout/stderr. Since one of the goals of webbrowser is to give the end-user a stress-free experience, there goes the mentioned nullification <wink>.
I see the point. Still I don't know what is worse and more stressful - to hide errors or to show errors. MandrakeZilla spits too much to stdout/err? That's certainly a problem. Should we "fix" it and hide from the user? I don't think so. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
[Rod Senra]:
Under some linux distros (I'm positive for some Mdk releases), Mozilla is compiled dumping a lot of info to stdout/stderr. Since one of the goals of webbrowser is to give the end-user a stress-free experience, there goes the mentioned nullification <wink>.
[Oleg Broytmann]:
I see the point. Still I don't know what is worse and more stressful to hide errors or to show errors. MandrakeZilla spits too much to stdout/err? That's certainly a problem. Should we "fix" it and hide from the user? I don't think so.
That is undoubtly a good argument. In general, if the end user could fix or report a problem based on a stdout/stderror message, I couln't agree more on keeping them flowing. However, there are two other issues: 1) If a *graphical* application dumps messages to the console, that might be disruptive to other console applications. IMVHO, a log file should be used instead. (strong argument) 2) If a dummy user sees a warning or info message in stdout/stdin that is not necessarily critical, it might interpret it wrongly as a error message and generate a false bug report. (weak argument) In the case of webbrowser.py, since detection process might face a diverse plethora of browsers (even unknown if defined by environment variables), we cannot predict if 1) or 2) will ever happen. Therefore, my -1 vote in my previous reply. But I do see your point <wink>. Has this same issue been dealt in another stdlib module ? best regards, Rod Senra
On Wed, Mar 23, 2005 at 11:59:24AM -0300, Rodrigo Dias Arruda Senra wrote:
Has this same issue been dealt in another stdlib module ?
pydoc.py: rc = os.system('netscape -remote "openURL(%s)" &' % url) if rc: os.system('netscape "%s" &' % url) PS. This, of course, should must be fixed - pydoc must use webbrowser.py! Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Oops...
PS. This, of course, should must be fixed - pydoc must use webbrowser.py! ^^^^^^ delete (-:
Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Wednesday 23 March 2005 08:25, Rodrigo Dias Arruda Senra wrote:
Under some linux distros (I'm positive for some Mdk releases), Mozilla is compiled dumping a lot of info to stdout/stderr. Since one of the goals of webbrowser is to give the end-user a stress-free experience, there goes the mentioned nullification <wink>.
This sounds familliar. This was certainly true when Mozilla was young and I actually wrote the webbrowser module. (Or was that, when Grail was young? I don't even remember if there was a Mozilla for the first version!)
In a development environment, a developer should not find difficulty to reverse that if needed.
Right. I think if the API provides a control for this and some mention is made in the documentation, that would be good. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
On Wednesday 23 March 2005 07:40, Oleg Broytmann wrote:
While I'm working on webbrowser... Why do all graphical browsers are called with their stdout/stderr redirected to /dev/null? Do we really need to hide problems from the user? Browsers are usually silent beasts - they interact with the user using windows, not stdio.
I don't remember why I did that; feel free to remove it. If it's actually useful, then 1) it should turn up before 2.5 final anyway, 2) we really want to know why, even if it just turns into a code comment, and 3) it should probably be controllable via the API, if its useful at all. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
On Wed, Mar 23, 2005 at 06:39:41PM -0500, Fred L. Drake, Jr. wrote:
On Wednesday 23 March 2005 07:40, Oleg Broytmann wrote:
While I'm working on webbrowser... Why do all graphical browsers are called with their stdout/stderr redirected to /dev/null? Do we really need to hide problems from the user? Browsers are usually silent beasts - they interact with the user using windows, not stdio.
I don't remember why I did that
I found one reason. For browsers that support remote commands the module runs two command - one to try to run the remote command, and another to run the browser in non-remote mode if the first command fails (there is no remote browser). If the remote command fails it reports the problem on stderr, but that's not an error from the module point of view, so the module hides it. But for the second command - browser + URL in non-remote mode - the module should not hide errors. I'll fix that. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On 23 March 2005, Oleg Broytmann said:
I'd like to remove all those redirects. Any opinion?
+0.5. The beauty of Python is that it generally provides thin
wrappers: when writing a convenient wrapper, it's OK to expose the
underlying beast, warts and all.
(I had a minor epiphany about this recently when digging into
ossaudiodev again: turns out that certain ioctls are implemented subtly
differently in OSS and in ALSA's OSS emulation layer. ossaudiodev, as
it turns out, faithfully mirrors this inconsistency to Python
programmers. The inconsistency is not ossaudiodev's fault, so it's not
ossaudiodev's problem to fix it. Python programmers should have access
to everything that C programmers have access to, only with less typing.
If that means they have to worry about Mozilla dumping lots of text to
stdout, or ALSA implementing certain ioctls differently than OSS, so be
it.)
(But, oh yeah: +1 to Fred's suggestion of making redirection
controllable. Something like this: default should be no redirection,
programmer should be allowed to specify what to do with stdout/stderr of
GUI browsers.)
Greg
--
Greg Ward
participants (4)
-
Fred L. Drake, Jr. -
Greg Ward -
Oleg Broytmann -
Rodrigo Dias Arruda Senra