Tell HN: Please don't print –help to stderr in your CLI tools

Re:Tell HN: Please don't print –help to stderr in your CLI t... by figmert on Thursday September 28, 2023 @09:19AM (#37689211)

Sure, but adding --help to a command means that the output of help is not exceptional, thus you're expecting it in stdout. If on the other hand you invoke the command incorrectly, and the author decides the best thing to do is print out the help in such cases, then yes, it should be stderr.

[ Parent | on HN ]

Re:Tell HN: Please don't print –help to stderr in your CLI t... by dingosity on Thursday September 28, 2023 @01:54PM (#37693173)

Let's take the cut command for instance. If you read the man page you discover it's job is to parse fields out of each line of input. Printing a usage message into STDOUT is not part of its documented behaviour. It is therefore an exceptional event.

[ Parent | on HN ]

Re:Tell HN: Please don't print –help to stderr in your CLI t... by rahimnathwani on Saturday September 30, 2023 @04:34PM (#37719498)

cut does the right thing:

- if you run cut with no input and no parameters, it outputs an error message to STDERR

- if you run cut --help it outputs usage info to STDOUT

This is what I'd expect based on the man page. Running cut with no parameters is undefined, hence the output to STDERR. Running cut --help is defined, so the output goes to STDERR.

I think people get confused because some tools, when run without any input, output the full help info to STDERR, instead of suggesting the user run foo --help*.

So foo* and foo --help* appear to be equivalent. Until you pipe into less*.

[ Parent | on HN ]