3 ms·

Not equivalent. If you want to insert an intermediary processing stage between the input file and the grep, the initial cat makes that a mechanical insertion, m

by kqr 4y ago

Not equivalent. If you want to insert an intermediary processing stage between the input file and the grep, the initial cat makes that a mechanical insertion, mirroring the intention in syntax. Without the cat, it's a more complex transformation.

loa_in_ 4y ago
Additionally it costs almost nothing to run a cat, but some mental work to remember which programs are built to prevent it (accept filename argument). If they are one can pass /proc/self/fd/0 as filename... That's some mindless tinkering that works so universally that it's just practical
- ithkuil 4y ago
  You can reduce the cognitive overhead by using this pattern: Before: <input.txt sed ... | awk ... After: <input.txt grep bar | sed ... | awk .. Every new pipeline stage is just "command args |" and you insert it after the end of a previous command, treating the initial input redirect as the end of zeroth command
  - Izkata 4y ago
    ...that increases the mental overhead because now there's no delimiter between the first and second part of the pipeline.
    - ithkuil 4y ago
      in zsh you can do this: <input.txt | grep bar | sed ... | awk .. but not in bash
- deleted 4y ago
  [deleted]
samuell 4y ago
Exactly this. I.e. I often back and forth comment out parts of a pipeline, when debugging. Thus, with `cat [file] | grep [ex]` I could do: cat [file] | less # | grep [ex] ... to quickly check the output of the unprocessed data, before uncommenting again. This is not possible with `grep [ex] [file]`. The power of this of course shines the most when having really long pipes, of up to or over 10 parts (which I've had lots of in my career). (Addendum: Well, I of course actually have an alias s='less -S' to make this even more fluent, so I do: cat [file] | s # | grep [ex] ... to peek into various parts of a pipeline. -S is for not folding long lines.)

by kqr 4y ago

loa_in_ 4y ago

Additionally it costs almost nothing to run a cat, but some mental work to remember which programs are built to prevent it (accept filename argument). If they are one can pass /proc/self/fd/0 as filename... That's some mindless tinkering that works so universally that it's just practical

ithkuil 4y ago
You can reduce the cognitive overhead by using this pattern: Before: <input.txt sed ... | awk ... After: <input.txt grep bar | sed ... | awk .. Every new pipeline stage is just "command args |" and you insert it after the end of a previous command, treating the initial input redirect as the end of zeroth command
- Izkata 4y ago
  ...that increases the mental overhead because now there's no delimiter between the first and second part of the pipeline.
  - ithkuil 4y ago
    in zsh you can do this: <input.txt | grep bar | sed ... | awk .. but not in bash
deleted 4y ago
[deleted]

samuell 4y ago

Exactly this. I.e. I often back and forth comment out parts of a pipeline, when debugging. Thus, with `cat [file] | grep [ex]` I could do: cat [file] | less # | grep [ex] ... to quickly check the output of the unprocessed data, before uncommenting again. This is not possible with `grep [ex] [file]`. The power of this of course shines the most when having really long pipes, of up to or over 10 parts (which I've had lots of in my career). (Addendum: Well, I of course actually have an alias s='less -S' to make this even more fluent, so I do: cat [file] | s # | grep [ex] ... to peek into various parts of a pipeline. -S is for not folding long lines.)