Are there any additional advantages of cat'ing a file and piping it to grep, besides convenience? The convenience being that, when I retrieve commands such as those below from my history, the cursor is at the end of the line, so it is easy to modify the command with different text to grep against the same file.
So what other advantages might there be to the following convention:
cat /var/tmp/trace.2043925204.xt | grep -in profile
cat /var/tmp/trace.2043925204.xt | grep -n Profile-Maininstead of:
grep -in profile /var/tmp/trace.2043925204.xt
grep -n Profile-Main /var/tmp/trace.2043925204.xt 7 Answers
Better to avoid cat; write it this way if line editing matters:
$ < filename grep pattern
The reason is that pushing all the data through cat costs memory and CPU resources. Another benefit of passing the filename as an argument rather than redirect stdin is that it allows the command the option to mmap() the file.
I can't believe no one has referenced "Useless Use of Cat" yet
There is one questionable advantage. If you have a long pipeline, it looks a bit more orthogonal with cat:
cat file | command1 | command 2 | command3It clusters all the commands together.
Of course as others have said (and I do)
< file command1 | command2 | command3Performs pretty much the same thing. That said, cat is pretty small and won't bring your computer down if you use it when you don't really need to.
Normally using cat vs directly hitting a file doesn't change anything, but it does make a difference for certain commands that care if there are multiple files as arguments, such as grep. Case in point:
cat file1 file2 | grep SOMETHINGwill have different output than
grep SOMETHING file1 file2Which will have the matching filenames in the output. There are times I don't want the filenames, and it's an advantage using cat.
There is no advantage. Your cursor being at the end also doesn't matter much if you structure it like this instead: < inputfile grep -args foo
You simply do not need to use cat in this situation at all. It is unnecessary and a waste of time, because tools such as grep take file names as arguments.
[root@un1xf00 root]# time cat passwd | grep root
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin
real 0m0.021s
user 0m0.000s
sys 0m0.030s
[root@un1xf00 root]# time grep root passwd
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin
real 0m0.002s
user 0m0.000s
sys 0m0.000s
[root@un1xf00 root]#Update: Thanks, @Andy Lester, for pointing out that these timings do not take into account disk cache. I learnt something new! But savings of a fraction of a second do not make much of a difference anyway. I just think piping cat into grep isn't a logical way of doing things. It's like asking someone else to help you with a problem, when you are perfectly capable of solving it yourself.
3Ease of editing is the only real advantage, and if you're doing it at the command line, any additional time it takes to run the cat and do the pipe won't really make a difference.
There's no reason to do it in a shell script, though.
There is no benefit at all. Instead of worrying about modifying the commands, learn to better navigate your shell command line with accelerator keys and shortcuts.
No and it might even be minutely slower in the example you give.
A pipe is created between cat and grep, which isn't required when passing the filename directly to grep. However I don't think under any circumstances will you ever observe throughput limitations because of this.
Other advantages of piping input to grep include additional processing prior, such as the use of utilities with more advanced file reading capabilities. (See tee, zcat, among others).
