Re: Bug#295328: general: Help messages to stderr should be banned
On Tue, Feb 15, 2005 at 09:13:32AM -0800, Thomas Bushnell BSG wrote: Francesco P. Lovergine [EMAIL PROTECTED] writes: Quite difficult if the function is the same. In both cases it uses stderr. Oh good grief. Add an argument to the function saying where to direct the output. How hard is this? Oh, well guys, I did not say it's correct. Just, a lot of people out there are too lazy to write the code in the right manner. Even if trivial. Well, a lot of people is also too lazy to use snprintf() instead of sprintf(). That is a bit worst :-D -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
On Tue, Feb 15, 2005 at 10:19:12AM +0100, Marco d'Itri wrote: On Feb 15, Justin Pryzby [EMAIL PROTECTED] wrote: I suppose I will start filing minor bugs against packages that do this. I'd like to hear other people's opinions, though. (It occurs to me that help output to stderr is arguably appropriate if an invalid option is given). Part of the problem is that its fairly depressing WTF? This is a long-time UNIX tradition, So your best rebuttal is It's tradition!? Strong argument you've got there. I'd summarily close such a bug opened on one of my packages. Good for you. - Matt signature.asc Description: Digital signature
Re: Bug#295328: general: Help messages to stderr should be banned
On Tue, 15 Feb 2005 10:19:12 +0100 [EMAIL PROTECTED] (Marco d'Itri) wrote: On Feb 15, Justin Pryzby [EMAIL PROTECTED] wrote: I suppose I will start filing minor bugs against packages that do this. I'd like to hear other people's opinions, though. (It occurs to me that help output to stderr is arguably appropriate if an invalid option is given). Part of the problem is that its fairly depressing WTF? This is a long-time UNIX tradition, I'd summarily close such a bug opened on one of my packages. Indeed, that's the only way people bothers to learn the 21|pager mantra ;-) -- Ricardo Mones Lastra - [EMAIL PROTECTED] Centro de Inteligencia Artificial, Universidad de Oviedo en Gijon 33271 Asturias, SPAIN. - http://www.aic.uniovi.es/mones -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
ti, 2005-02-15 kello 10:19 +0100, Marco d'Itri kirjoitti: On Feb 15, Justin Pryzby [EMAIL PROTECTED] wrote: I suppose I will start filing minor bugs against packages that do this. I'd like to hear other people's opinions, though. (It occurs to me that help output to stderr is arguably appropriate if an invalid option is given). Part of the problem is that its fairly depressing WTF? This is a long-time UNIX tradition, I'd summarily close such a bug opened on one of my packages. In my opinion, if you give a wrong option (or do some other syntax error on the command line), the proper thing to do is to give an error message, preferably short, saying what the error was and how to get the full help text. This is an error message, so it should go to the standard error output. When the user explicitly requests for a help text, it is not an error and should go to the standard output. GNU tools work like this already, and have, to the best of my knowledge, worked like this for well over a decade. Tools that behave differently are also fairly common, so I guess tradition isn't clearcut here. I do claim that the GNU way is the right way here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
Francesco P. Lovergine writes: It depends on programs, sometimes the same usage function is used for either --help or invalid options. Sure, but the output should still be directed correctly. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
On Tue, Feb 15, 2005 at 07:38:08AM -0600, John Hasler wrote: Francesco P. Lovergine writes: It depends on programs, sometimes the same usage function is used for either --help or invalid options. Sure, but the output should still be directed correctly. Quite difficult if the function is the same. In both cases it uses stderr. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
On Tue, Feb 15, 2005 at 03:06:19PM +0100, Francesco P. Lovergine wrote: On Tue, Feb 15, 2005 at 07:38:08AM -0600, John Hasler wrote: Francesco P. Lovergine writes: It depends on programs, sometimes the same usage function is used for either --help or invalid options. Sure, but the output should still be directed correctly. Quite difficult if the function is the same. In both cases it uses stderr. So you change the program to take a file descriptor into the help-printing function, or provide some other means of determining where to send the output. - Matt signature.asc Description: Digital signature
Re: Bug#295328: general: Help messages to stderr should be banned
On Tue, Feb 15, 2005 at 03:06:19PM +0100, Francesco P. Lovergine wrote: On Tue, Feb 15, 2005 at 07:38:08AM -0600, John Hasler wrote: Francesco P. Lovergine writes: It depends on programs, sometimes the same usage function is used for either --help or invalid options. Sure, but the output should still be directed correctly. Quite difficult if the function is the same. In both cases it uses stderr. A computer can technically do anything; difficulty results from (an) incorrect decision(s) by (a) programmer(s). -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
Francesco P. Lovergine [EMAIL PROTECTED] schrieb:
On Tue, Feb 15, 2005 at 07:38:08AM -0600, John Hasler wrote:
Francesco P. Lovergine writes:
It depends on programs, sometimes the same usage function is used for
either --help or invalid options.
Sure, but the output should still be directed correctly.
Quite difficult if the function is the same. In both cases it uses stderr.
#!/bin/sh
usage(){
if [ $1 = STDERR ]; then
EXITCODE=1
exec 2;
else
EXITCODE=0
fi
echo bla...
exit $EXITCODE
}
case $1 in
--help|-h|-help)
usage;;
--foo)
...
*)
usage STDERR;;
esac
Translation to Perl, Python, C, whatever, and to multiple arguments is
left to the reader as an afternoon exercise.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Re: Bug#295328: general: Help messages to stderr should be banned
Francesco Paolo Lovergine [EMAIL PROTECTED] writes: It depends on programs, sometimes the same usage function is used for either --help or invalid options. Not always GNU rules are followed appropriately. Right, and in that case, it's a bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
Francesco P. Lovergine [EMAIL PROTECTED] writes: Quite difficult if the function is the same. In both cases it uses stderr. Oh good grief. Add an argument to the function saying where to direct the output. How hard is this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
On Mon, Feb 14, 2005 at 11:06:30PM -0500, Justin Pryzby wrote: [...] I occasionally install a program and need to know how to use it as quickly as possible; for example, while reading through bug reports. So, I run foo --help. Sometimes, the help screen is more than 25 lines long, and it scrolls on past. So, I run foo --help |less. Occasionally, though, foo writes its help output to stderr, and I'm left with an empty less buffer. So, I try again: foo --help 21 |less. This is a pretty obnoxious command to have to type just to see what the required commands are, and in what order they are taken (and, I guess csh doesn't even allow it). [...] Actually, in csh/tcsh it's very un-obnoxious: foo --help | less This is one of the things I wish bash supports, so that I can switch to bash. (I use csh/tcsh as my primary shell.) FWIW. T -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
On Tue, 15 Feb 2005, Frank Küster wrote:
Francesco P. Lovergine [EMAIL PROTECTED] schrieb:
On Tue, Feb 15, 2005 at 07:38:08AM -0600, John Hasler wrote:
Francesco P. Lovergine writes:
It depends on programs, sometimes the same usage function is used for
either --help or invalid options.
Sure, but the output should still be directed correctly.
Quite difficult if the function is the same. In both cases it uses stderr.
#!/bin/sh
usage(){
if [ $1 = STDERR ]; then
EXITCODE=1
exec 2;
else
EXITCODE=0
fi
echo bla...
exit $EXITCODE
}
case $1 in
--help|-h|-help)
usage;;
--foo)
...
*)
usage STDERR;;
esac
Translation to Perl, Python, C, whatever, and to multiple arguments is
left to the reader as an afternoon exercise.
What's with all this complexity? Just redirect stdout to stderr when you call
the function. Geez.
==
usage() {
if [ $# -gt 0 ]; then
echo $@
fi
echo foo
echo baz
}
case $1 in
(-h)usage; exit 0;;
(*) usage Unknown option($1) 12; exit 1;;
esac
==
Re: Bug#295328: general: Help messages to stderr should be banned
On Tue, 15 Feb 2005 09:19:35 -0800
H. S. Teoh [EMAIL PROTECTED] wrote:
On Mon, Feb 14, 2005 at 11:06:30PM -0500, Justin Pryzby wrote:
[...]
I occasionally install a program and need to know how to use it as
quickly as possible; for example, while reading through bug reports.
So, I run foo --help. Sometimes, the help screen is more than 25
lines long, and it scrolls on past. So, I run foo --help |less.
Occasionally, though, foo writes its help output to stderr, and I'm
left with an empty less buffer. So, I try again: foo --help 21
|less. This is a pretty obnoxious command to have to type just to
see what the required commands are, and in what order they are taken
(and, I guess csh doesn't even allow it).
[...]
Actually, in csh/tcsh it's very un-obnoxious: foo --help | less
This is one of the things I wish bash supports, so that I can switch
to bash. (I use csh/tcsh as my primary shell.)
bash can be easily forced to be even more un-obnoxious, put:
function helpof()
{
$1 --help 21|pager
}
in your ~/.bashrc, then helpof command gives you all.
Shorten function name to your likings and probably you have to type less
than with command --help.
--
Ricardo Mones Lastra - [EMAIL PROTECTED]
Centro de Inteligencia Artificial, Universidad de Oviedo en Gijon
33271 Asturias, SPAIN. - http://www.aic.uniovi.es/mones
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
H. S. Teoh [EMAIL PROTECTED] writes: Actually, in csh/tcsh it's very un-obnoxious: foo --help | less zsh too. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
This one time, at band camp, Matthew Palmer said: On Tue, Feb 15, 2005 at 03:06:19PM +0100, Francesco P. Lovergine wrote: On Tue, Feb 15, 2005 at 07:38:08AM -0600, John Hasler wrote: Francesco P. Lovergine writes: It depends on programs, sometimes the same usage function is used for either --help or invalid options. Sure, but the output should still be directed correctly. Quite difficult if the function is the same. In both cases it uses stderr. So you change the program to take a file descriptor into the help-printing function, or provide some other means of determining where to send the output. I just recently sent a patch upstream for hdparm for exactly this, implemented exactly this way, since his previous implementation was a single function that was reused. It is trivial to do so, and it is also the Right Thing, IMHO. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpW0bNWMNDvh.pgp Description: PGP signature
Re: Bug#295328: general: Help messages to stderr should be banned
[EMAIL PROTECTED] (Marco d'Itri) writes: I suppose I will start filing minor bugs against packages that do this. I'd like to hear other people's opinions, though. (It occurs to me that help output to stderr is arguably appropriate if an invalid option is given). Part of the problem is that its fairly depressing WTF? This is a long-time UNIX tradition, I'd summarily close such a bug opened on one of my packages. It's not clear what you're talking about here. It's certainly correct (and tradition) for _error messages_ to go to stderr. However, --help output _is not an error message_. It is program output, produced in response to an explicit user request. Programs that send --help output to stderr are annoying for any user, and doubly so for inexperienced users that may not know how to redirect stderr (e.g., with 21). These are the reasons that the GNU standards specify that --help output should go to stdout, not stderr. [There are many non-GNU programs (and some GNU programs that don't follow the standards properly) that send --help output to stderr, but there seems to be no particular tradition about it -- basically prior to GNU, people didn't seem to think very hard about this issue, and it was pretty random whether stderr or stdout was used.] -Miles -- /\ /\ (^.^) ()) *This is the cute kitty virus, please copy this into your sig so it can spread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
Justin Pryzby writes: It occurs to me that help output to stderr is arguably appropriate if an invalid option is given But '--help' is not an invalid option. I'll have to check my packages. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
On Mon, Feb 14, 2005 at 10:47:24PM -0600, John Hasler wrote: Justin Pryzby writes: It occurs to me that help output to stderr is arguably appropriate if an invalid option is given But '--help' is not an invalid option. It depends on programs, sometimes the same usage function is used for either --help or invalid options. Not always GNU rules are followed appropriately. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
