Advantages of cat'ing file and piping to grep

Question

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-Main

instead of:

grep -in profile /var/tmp/trace.2043925204.xt 
grep -n Profile-Main /var/tmp/trace.2043925204.xt 

Solution 1

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.

Solution 2

I can't believe no one has referenced "Useless Use of Cat" http://www.smallo.ruhr.de/award.html 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 | command3

It clusters all the commands together.

Of course as others have said (and I do)

< file command1 | command2 | command3

Performs 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 SOMETHING

will have different output than

grep SOMETHING file1 file2

Which will have the matching filenames in the output. There are times I don't want the filenames, and it's an advantage using cat.

Solution 3

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

Solution 4

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.

Solution 5

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

View more solutions

Comments

[Dennis Williamson]

@Michael: A -10 to you for being obtuse. You could have been more helpful. Too bad you won't see this since you don't have an account here.

[RonJohn]

cat is much clearer to read than <. Or maybe just for us fogeys who think that Unix and bash could learn a heck of a lot from VMS and DCL.