[scubbo]

Hopefully this[0] should be the last word on "useless" uses of cat

> When I offer a pipeline as a solution I expect it to be reusable. It is quite likely that a pipeline would be added at the end of or spliced into another pipeline. In that case having a file argument to grep screws up reusability, and quite possibly do so silently without an error message if the file argument exists. I. e. `grep foo xyz | grep bar xyz | wc` will give you how many lines in xyz contain bar while you are expecting the number of lines that contain both foo and bar. Having to change arguments to a command in a pipeline before using it is prone to errors. Add to it the possibility of silent failures and it becomes a particularly insidious practice.

[0] https://stackoverflow.com/a/16619430/1040915

[hddqsb]

No such thing as "last word" :)

See Jonathan Leffler's comment on SO (also demonstrated by the the top-level parent comment here):

> As noted in the answer by kojiro, it is perfectly possible and legal to start the pipeline with `< file command1 ...`. Although the conventional position for the I/O redirection operators is after the command name and its arguments, that is only the convention and not a mandatory placement. The `<` does have to precede the file name. So, there's a close to perfect symmetry between `>output` and `<input` redirections: `<input command1 -opt 1 | command2 -o | command3 >output`.

[scubbo]

Sure, and as another answerer of that SO question points out[0]:

> We are used to read from left to right, so a command like

> `cat infile | process1 | process2 > outfile`

> is trivial to understand.

> `process1 < infile | process2 > outfile`

> has to jump over process1, and then read left to right. This can be healed by:

> `< infile process1 | process2 > outfile`

> looks somehow, as if there were an arrow pointing to the left, where nothing is.

Sure, you can have the inputfile precede the process, but then you have to precede _that_ with a glyph which appears to suggest "send this data to the preceding command". You know and I know that that's not what `<infile` really means, but I claim (and others are free to subjectively disagree) that, in the context of an exploratory gradually-incrementing bash query, the extra brain cycles to remember what `<infile` really means are not worth the extra compute cycles of the extra process of a "useless" cat.

To someone who's fully internalized the workings of the shell, then sure, using `<infile` is _technically_ more efficient, at the expense of being less readable to less-experienced engineers. The tradeoff between readability and performance is always a case-by-case decision.

[0] https://stackoverflow.com/a/49254166/1040915