3 ms·

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

by scubbo 4y ago

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 https://stackoverflow.com/a/16619430/1040915

hddqsb 4y 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`.
- scubbo 4y ago
  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 https://stackoverflow.com/a/49254166/1040915

by scubbo 4y ago

hddqsb 4y 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`.

scubbo 4y ago
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 https://stackoverflow.com/a/49254166/1040915