5 ms·

Last time I posted a link to that, I received quite a few replies where people find it more natural to use `cat file | …` even when unnecessary — so even though

Last time I posted a link to that, I received quite a few replies where people find it more natural to use `cat file | …` even when unnecessary — so even though I agree with the intent of the page I feel like it's useless to try and evangelise every case. If cat is the bottleneck though, fair game.

jfhufl 8y ago
One good reason (IMO) for doing "cat file |" is it's easier to grab the command from your history and change it to something like "grep foo file |" rather than if you had run "cmd < file".
- jgtrosh 8y ago
  My counter argument would be that with a good shell line editor like zsh in vi mode command transformations are as cheap as modular grammar; however I know there's limits to that argument (Java is only writeable in Java IDEs) so I'll grant you that :-)
- waterhouse 8y ago
  Also, if you have a long pipeline: cat file | this | that | other | out vs this < file | that | other | out In the cat example, it's easy to change the head of the pipeline, by adding things before "this" or deleting "this", which is less so in the non-cat example. (The use case I have in mind is experimental commands that take probably <10s to complete, where editing time is a significant fraction of the time you spend.)
  - deleted 8y ago
    [deleted]
  - iforgotpassword 8y ago
    < file this | that | other | out
  - deleted 8y ago
    [deleted]
- deleted 8y ago
  [deleted]
e12e 8y ago
First, if cat is slower than redirection from file (<file) - then I'd say something is amiss. But more to the point - I think it's really a bug that tools like gzip, grep, awk etc work on files at all. We do need a tool to feed files to pipes (I think cat is a fine candidate for that - also when we only con-cat-enate one file (the identity cat, if you will). Maybe there are cases where a long string of awk|something|other|sort|uniq is not the problem, but forking an extra process for cat is. And maybe there's a mismatch between pipes, files and mmap today. Splice seems like a reasonable fix (if we splice all the things, awk, grep etc). Finally, I just think: cat input.txt \ | filter1 args \ | filter2 args \ | reduction \ | ouput-formater Reads better than having to tack on an <input.txt at the end, or special-case the first filter to be (... And also open a file).
- Pete_D 8y ago
  You don't have to put the redirection at the end, you can write < input.txt filter1 args # ... rest of pipeline (But I agree that the cat version is more readable.)
  - e12e 8y ago
    True. I might not mind as much if it was (possible to, in a sane way, do): "< input | (...)"
- btschaegg 8y ago
  > I think it's really a bug that tools like gzip, grep, awk etc work on files at all. I'd say that is somewhat of a harsh premise, especially since the in-place editing of files available e.g. in many GNU tools (awk, sed, sort) is really useful and based on exactly that possibility. I do agree that cat often makes pipes easier to read, though. And yes, obsessing over that one additional process seems to be somewhat silly. Unless, of course, it introduces a real bottleneck and the whole thing is time sensitive.
- madmax96 8y ago
  >if cat is slower than redirection from a file - then I'd say something is amiss With `cat`, a new process must be created. But with shell redirection, no new process is necessarily created, so that is going to be faster.

jfhufl 8y ago

One good reason (IMO) for doing "cat file |" is it's easier to grab the command from your history and change it to something like "grep foo file |" rather than if you had run "cmd < file".

jgtrosh 8y ago
My counter argument would be that with a good shell line editor like zsh in vi mode command transformations are as cheap as modular grammar; however I know there's limits to that argument (Java is only writeable in Java IDEs) so I'll grant you that :-)
waterhouse 8y ago
Also, if you have a long pipeline: cat file | this | that | other | out vs this < file | that | other | out In the cat example, it's easy to change the head of the pipeline, by adding things before "this" or deleting "this", which is less so in the non-cat example. (The use case I have in mind is experimental commands that take probably <10s to complete, where editing time is a significant fraction of the time you spend.)
- deleted 8y ago
  [deleted]
- iforgotpassword 8y ago
  < file this | that | other | out
- deleted 8y ago
  [deleted]
deleted 8y ago
[deleted]

e12e 8y ago

First, if cat is slower than redirection from file (<file) - then I'd say something is amiss. But more to the point - I think it's really a bug that tools like gzip, grep, awk etc work on files at all. We do need a tool to feed files to pipes (I think cat is a fine candidate for that - also when we only con-cat-enate one file (the identity cat, if you will). Maybe there are cases where a long string of awk|something|other|sort|uniq is not the problem, but forking an extra process for cat is. And maybe there's a mismatch between pipes, files and mmap today. Splice seems like a reasonable fix (if we splice all the things, awk, grep etc). Finally, I just think: cat input.txt \ | filter1 args \ | filter2 args \ | reduction \ | ouput-formater Reads better than having to tack on an <input.txt at the end, or special-case the first filter to be (... And also open a file).

Pete_D 8y ago
You don't have to put the redirection at the end, you can write < input.txt filter1 args # ... rest of pipeline (But I agree that the cat version is more readable.)
- e12e 8y ago
  True. I might not mind as much if it was (possible to, in a sane way, do): "< input | (...)"
btschaegg 8y ago
> I think it's really a bug that tools like gzip, grep, awk etc work on files at all. I'd say that is somewhat of a harsh premise, especially since the in-place editing of files available e.g. in many GNU tools (awk, sed, sort) is really useful and based on exactly that possibility. I do agree that cat often makes pipes easier to read, though. And yes, obsessing over that one additional process seems to be somewhat silly. Unless, of course, it introduces a real bottleneck and the whole thing is time sensitive.
madmax96 8y ago
>if cat is slower than redirection from a file - then I'd say something is amiss With `cat`, a new process must be created. But with shell redirection, no new process is necessarily created, so that is going to be faster.