On the other hand, a system that has been designed coherently is much nicer to use.

But the flip side of this is, yes, cruft.

The word you’re looking for is “condescending”.

Regardless, there is no argument about software freedom to be made here.

You’re allowed, be it open or close source, to write and publish software that defies common, well-established conventions.

You can pretend that it’s some sort of first amendment right to do so if you like, and attempt to deflect your unwillingness to write software that behaves properly as incompetence on the users’ end.

But whether anyone will be convinced by that is a separate question, and those who aren’t convinced certainly have the right to tell you, in turn, that your software sucks. This does not inflige on your rights to write broken software.

Yup, sounds pretty snotty.

Is there no value in following a convention?

This is sort of my hot button issue. After years of working on BSAFE, OpenSSL, firefox and libnss, I hate that people say "Hey. Great software. Here's a list of things you must add to it. Of course I'm not going to pay you."

Why should I change my code to adhere to someone else's conventions when they're in opposition to existing conventions?

You really do not need to be such a grumpy elitist. People are not born with Unix knowledge already in their heads. Asking questions, raising doubts, and getting answers from more knowledgeable users is a very effective way of learning new things!

With that said, can you make an example of a legitimate use of `command1 --help | command2`, where `command2` does something useful and is not `less`?

More importantly, I can easily find things by searching with less's `/` hotkey. Relying on the terminal emulator's built-in search isn't great because (a) I'm not used to it - I am more used to vim's keybindings, and the search hotkey `/` is the same in vim, and (b) that's also going to search all the output from before I ran --help (not as big of a gripe, but still somewhat annoying).

And if your brain is wired for vi, then that makes complete sense.

But... the cool thing about using the scrollwheel to scroll up to see the --help output is it's always there. If you pipe it into less, it disappears as soon as you exit less. So if you're writing a big, beefy command with lots of unfamiliar options, you can start typing down at the prompt and then scroll up to read the help output. It's annoying when you type that you immediately scroll back down to the bottom of the terminal buffer, and I think all terminal emulators default to doing this, but maybe it's a configurable behaviour.

This also works with `man <command> | cat`.

Also... how many times have I had to type out `git branch -a | cat` and tried to remember to put the `| cat` in it. I HATE that the stock git cli automagically pipes to /usr/bin/pager. If I wanted to pipe the output to /usr/bin/pager, I would type `command | /usr/bin/pager`. But now I'm just kvetching.

(Alacritty has a tonne of great features I just haven't taken the time to learn the muscle memory to use.. ctrl-j/k bindings to scroll back and some custom patterns to open as URLs is about it.)

The problem isn't that you get a usage message when you ask for it. It's that you get a usage message (written to STDOUT) when you don't. Many commands will print out the usage message when command line options specify a condition that can't be met. I find this frequently when ssh'ing into busybox based systems. Busybox's find command is much less "refined" than comparable desktop OS finds (BSD & GNU/Linux).

So if I do something like:

  ssh [email protected] "find . -type f | while read line; do sha256sum \$line; done" | tr -s ' ' | cut -f 2,1 -d ' ' | sort | uniq -c

- 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*.

I use the shell almost daily, and have shipped industry-leading products.

2>&1 is a vague memory because I'm not sure if I've ever done that; and I certainly shouldn't have to know some arcane shell trick to read the manual.

I use much more complicated pipe tricks than that interactively on a daily basis, and I definitely don't think of them as "arcane". As somebody who does that, it's useful to me to know which channel the data I want to pipe are going to come out on. Which is why help, which is normal requested output, should obviously go to stdout.

Usage messages issued in response to actual user errors are different, of course.

Also, if you needed to use it every day, I suspect it would be more familiar than a vague memory.

I don't pipe command output daily, though. I use the shell because often it's easier than point-and-click for a lot of operations.

The shell has plenty of use cases that don't involve piping output. Saying you shouldn't touch the shell unless you understand piping output is like saying you shouldn't touch a refrigerator unless you know the perfect temperature to store milk.

"Exceptional event" is not a useful or well defined concept. A better concept is "error" or "unexpected result".

Asking for help is a request for information. The normal, non-error, expected result is that a bunch of text will show up on the output. It is entirely reasonable that the "next command in the pipe" might want to do something with that expected output.

I shouldn't have to guess whether or not you think the output I specifically requested is "exceptional", so it's entirely reasonable to expect that programs in general consistently put user-requested help on stdout.

You are of course free to write your software any way you want. And I'm free to think it's stupid, and to not use your software.

Yes. You're unlikely to like my software. I don't recommend you use it.

Uh-huh. And then you get developers that do this (from inside a f#@<ing library, of all places):

  FILE *stream = (level == LOGGER_LEVEL_ERROR) ? stderr : stdout;