On Tue, May 2, 2017 at 8:59 PM, Dave Horsfall <dave@horsfall.org> wrote:
On Tue, 2 May 2017, Doug McIlroy wrote:
> With Steve's eloquent grump and cat -v on the table, I can't help
> re-citing the peerless cardinal sin of
>         less --help | wc

Speaking of "cat", what really drives me nuts is "cat file | cmd"...

What's wrong with "cmd < file" (or to really confuse newbies, "< file
cmd")?

Ooo! Ooo! Ooo! I've actually got something for this....

First of all, there's nothing strictly speaking *wrong* with 'cmd < file' and cat 'cat file | cmd' is definitely overused, often unintentionally and out of ignorance.

However, 'cmd <file' requires 'file' as a literal string in the command; `cat` can be useful when the file parameter may be optional. E.g., 'cat "$@" | ...'. Now some folks will immediately respond by saying, "many commands will read from stdin if a filename is not presented on the command line, so why not, 'cmd "$@"'?" And that's certainly a valid question, to which I would answer that the semantics of a command sometimes subtly change when presented with one or more filenames as argument (e.g. 'grep'), so using `cat` may suppress that behavior if desired. "But `grep` has the `-h` option to tell it not to print the filename!" Yes, but `grep` is just *one command* and not *all* of them do. The point being that 'cat' in a pipeline has it's place, even if that place is rarely the place we see it.

Another, related use to cover up one of the more odious of recent design decisions in Unix-like systems is to use `cat` at the *end* of the pipeline. Some programs change behavior if they know that they are writing into a tty; one can suppress that if one terminates the pipeline in `cat`. This is surely a case of mis-using a feature to mask a bug, but it's often useful regardless.

        - Dan C.