4 ms·

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

by 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.

by e12e 8y ago

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.