|
|
|
|
|
|
by hddqsb
1189 days ago
|
|
|
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`. |
|
|
> 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