21–30 of 60 posts
It's POSIX convention to write to stderr for anything that's not strict program output. I have seen 2>&1 far too often in scripts. I don't worry about it and happily write error messages to stderr whenever my scripts exit without a 0 status code.
Ah yes, Schroedinger's workflow. So important any disruption is a disaster, and simultaneously so unimportant they couldn't possibly spend a single dime on the tools critical to the workflow.
Earlier quoted context omitted.
Another thing that gets screwed up a lot is: Comand line usage help/information should be printed to stderr if it was invoked because the user passed an invalid option to the command line (in other words, the usage text counts as diagnostic[1] info), but it should be printed to stdout if the user invoked the application with -h, --help or similar. Reasons: 1. If you mess up the command line to the program in a script…
Disagree. stdout is only reserved for actual processed command output. It may be empty, it may be invalid because the input was invalid (shit in, shit out), but it may never be things intended for a human to read. If one wants to use a pager (like I sometimes do, though most of the time I just scroll up), they'll just use `foo 2>&1 | less`.
1: https://www.gnu.org/prep/standards/html_node/_002d_002dhelp....
Aren't you supposed to return a 0 status code when "yea done!" and some other status code when it wasn't done?
Indeed you're supposed to, but that way if someone calls exit(0), it looks like the program worked fine, when in fact they committed some debug code and made the program no longer run to completion. "Yay, done" was put in for the scripts to flag this sort of thing, presumably based on experience.
Earlier quoted context omitted.
Why not have the program exit with exit code 0 on success, and non-0 on failure, like almost every program in a POSIX environment ever ?
see yosefk reply above
Earlier quoted context omitted.
Disagree. stdout is only reserved for actual processed command output. It may be empty, it may be invalid because the input was invalid (shit in, shit out), but it may never be things intended for a human to read. If one wants to use a pager (like I sometimes do, though most of the time I just scroll up), they'll just use `foo 2>&1 | less`.
GNU offers guidance[1] to output --help to stdout, but it's not against the law to do it your way. 1: https://www.gnu.org/prep/standards/html_node/_002d_002dhelp....
Does no one know what exit codes and stderr vs. stdout is anymore? I work with old and new code bases used by many clients in complicated setups, but adding a warning to stderr while stdout was left untouched, and proper exit codes maintained, was hardly, if ever, a problem so far. Of course, there's always some unpleasant exception, but it's rare. And of course, I also understand that the author might have found the…
Earlier quoted context omitted.
Another thing that gets screwed up a lot is: Comand line usage help/information should be printed to stderr if it was invoked because the user passed an invalid option to the command line (in other words, the usage text counts as diagnostic[1] info), but it should be printed to stdout if the user invoked the application with -h, --help or similar. Reasons: 1. If you mess up the command line to the program in a script…
Disagree. stdout is only reserved for actual processed command output. It may be empty, it may be invalid because the input was invalid (shit in, shit out), but it may never be things intended for a human to read. If one wants to use a pager (like I sometimes do, though most of the time I just scroll up), they'll just use `foo 2>&1 | less`.
- sometimes you can get the status code, sometimes you can't.
- sometimes you can separate out stdout from stderr, sometimes you can't
- sometimes the program generating the error message identifies itself, sometimes it doesn't
- sometimes you don't know if you have a "good error" (ok to ignore) or a "bad error" (cannot ignore)
I am a fan of the HARD FAIL.
I think internal unit tests or things like that should hard fail, then get a human to either fix it, or put in a hard exception.
if it is user-facing... sigh