4 ms·

> Failing quietly was never a part of it. Not part of it, but not against it. It's useful to stay quiet when the program is meant for conditions and failure is

by jolmg 3y ago

> Failing quietly was never a part of it. Not part of it, but not against it. It's useful to stay quiet when the program is meant for conditions and failure is normal. For example: `test`/`[`, `false`, `grep` (when no matches are found), etc. Also when the program is meant as a sort of wrapper to other programs, like `ssh localhost false`, `script -qec false /dev/null`, `true | xargs false`, etc. > A message like "incorrect arguments, use --help" can itself go to stderr. Not --help itself though. I don't agree that it's incorrect to save the user the step of calling --help, when it's obvious they need to see that info from an incorrect call. Once decided that including the --help message in an error is right, I don't think it's correct to include it in stdout when it's not expected. This isn't an odd behavior either, including the --help message (or at least just the synopsis) in stderr on incorrect options is the behavior I'm seeing in utilities like GNU's `bash`, `grep`, and OpenBSD's `netcat`, for example.

kazinator 3y ago
If that bad command is in in a script where it is run 1000 times in a loop you don't want 1000 copies of the help text. The user doesn't always need help; maybe they just made a typo. Spewing help on every error gets old, fast. Much faster than a Unix graybeard gets old.
- deleted 3y ago
  [deleted]
- notpushkin 3y ago
  Yeah, but if it's run interactively a quick hint (and not the full help message) can be useful.
  - hnben 3y ago
    interactive and non-interactive use should diverge as little as possible. Personal, I like it, when a program directs me to its help-command, when I give it a bad option, like > openssl blabla Invalid command 'blabla'; type "help" for a list.
  - kazinator 3y ago
    You can't tell that in the program itself. Whether standard input is a TTY isn't a reliable indicator in either way. Though if you insist on spewing help text along side diagnostics, at least refraining from doing that to a non-TTY device might not be a bad idea.
- dredmorbius 3y ago
  Take grep as an example. If it doesn't find a match for the specified regex, it fails silently (and exits with a return value of 1). If the file isn't found, then grep reports that error, e.g., $ grep foo /doesnotexist grep: /doesnotexist: No such file or directory Mind that it's quite possible that that error might result from an improperly quoted or escaped multi-term regex (containing whitespace), e.g., $ grep foo bar baz /etc/bashrc grep: bar: No such file or directory grep: baz: No such file or directory In a well-designed bash script, you'd test the file and quote the regex, e.g., test -f somefile && grep 'foo bar baz' somefile Grep is verbose on error where that's useful, but not overly so. A tool which returns a (brief) usage note is "magick" (from the ImageMagick suite): $ magick --asdf Error: Invalid argument or not enough arguments Usage: magick tool [ {option} | {image} ... ] {output_image} Usage: magick [ {option} | {image} ... ] {output_image} magick [ {option} | {image} ... ] -script {filename} [ {script_args} ...] magick -help | -version | -usage | -list {option} There are others I've encountered which return a much longer help set. I believe opkg from OpenWRT is amongst those, which prints over 80 lines worth of options to stderr when given an invalid argument.
  - deleted 3y ago
    [deleted]

by jolmg 3y ago

kazinator 3y ago

If that bad command is in in a script where it is run 1000 times in a loop you don't want 1000 copies of the help text. The user doesn't always need help; maybe they just made a typo. Spewing help on every error gets old, fast. Much faster than a Unix graybeard gets old.

deleted 3y ago
[deleted]
notpushkin 3y ago
Yeah, but if it's run interactively a quick hint (and not the full help message) can be useful.
- hnben 3y ago
  interactive and non-interactive use should diverge as little as possible. Personal, I like it, when a program directs me to its help-command, when I give it a bad option, like > openssl blabla Invalid command 'blabla'; type "help" for a list.
- kazinator 3y ago
  You can't tell that in the program itself. Whether standard input is a TTY isn't a reliable indicator in either way. Though if you insist on spewing help text along side diagnostics, at least refraining from doing that to a non-TTY device might not be a bad idea.
dredmorbius 3y ago
Take grep as an example. If it doesn't find a match for the specified regex, it fails silently (and exits with a return value of 1). If the file isn't found, then grep reports that error, e.g., $ grep foo /doesnotexist grep: /doesnotexist: No such file or directory Mind that it's quite possible that that error might result from an improperly quoted or escaped multi-term regex (containing whitespace), e.g., $ grep foo bar baz /etc/bashrc grep: bar: No such file or directory grep: baz: No such file or directory In a well-designed bash script, you'd test the file and quote the regex, e.g., test -f somefile && grep 'foo bar baz' somefile Grep is verbose on error where that's useful, but not overly so. A tool which returns a (brief) usage note is "magick" (from the ImageMagick suite): $ magick --asdf Error: Invalid argument or not enough arguments Usage: magick tool [ {option} | {image} ... ] {output_image} Usage: magick [ {option} | {image} ... ] {output_image} magick [ {option} | {image} ... ] -script {filename} [ {script_args} ...] magick -help | -version | -usage | -list {option} There are others I've encountered which return a much longer help set. I believe opkg from OpenWRT is amongst those, which prints over 80 lines worth of options to stderr when given an invalid argument.
- deleted 3y ago
  [deleted]