31–40 of 60 posts
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`.
I see you've never tried to run command --help | less
Earlier quoted context omitted.
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....
I guess this is a point where I disagree with GNU. Then again, the reasons why I disagree are subtle enough that I don't care too much... I think this particular thing doesn't matter very much in practice, so go do your thing GNU...
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…
We, uh, reasoned with the other side - we told them to fix their stupid broken setup.
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…
I worked on a code base that ran on a variety of Unixes. One customer complained about file corruption from our software. Turns out that their Unix setup was... rather unique. Spawned programs were not given a stderr file handle! If you wrote to stderr, it scribbled on whatever file was open on file handle 2. We, uh, reasoned with the other side - we told them to fix their stupid broken setup.
Earlier quoted context omitted.
"People deliberately misuse the very mechanism that was designed to indicate successful completion, so we added another, flawed detection mechanism based on IO, because there's no way they'll do the thing that they should have learned in the first year of school, and just call exit with any other argument than 0 on irregular completion". Gosh I thought the engineering culture was bad where I work.
Yea, whatever you do, don't solve the actual problem! This reminds me of solving a buffer overflow by just blindly increasing the size of the buffer until it no longer crashes.
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…
Sounds like you don't use ffmpeg very often. Because ffmpeg is able to send its output to stdout to be piped to other apps, verbose text output can't use stdout as one would expect. Non-error text is sent to stderr instead. So when you want to trap the text output you have to route stderr to text file. It takes some getting used to, but it's now normal for me.
So, yeah, I know stderr vs stdout still, but it's not what you want it to simply be. In the real world, things are not as clean as they are in school books.
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.
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…
I'll use ffmpeg as an example of being an edge case. It's hard to get ffmpeg to give a nonzero exit code. What might be a problem for the user wasn't necessarily a problem for the app, so the app thinks it is completed and does its thing exiting with zero. For example, if a file is being read as input that is corrupted causing ffmpeg to no longer be able to read from the source, it will happily close your file cleanly so it is usable (just shorter than expected) and report it completed successfully. If all you do is check the exit code, you'll think your file is completed. Much more due diligence is necessary to be sure.
Earlier quoted context omitted.
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....
I guess this is a point where I disagree with GNU. Then again, the reasons why I disagree are subtle enough that I don't care too much... I think this particular thing doesn't matter very much in practice, so go do your thing GNU...