As mentioned in another answer, the cat
less variant isn't always equivalent. Sometimes cat
is even more secure. If you're using grep
to examine a log, then you have three basic choices:
grep 'pattern' /path/to/log
grep 'pattern' < /path/to/log
cat /path/to/log | grep "pattern"
For most things, you wouldn't notice a difference here, except in the number of key strokes you need. Now, what happens when log
has can only be read by root? I wanted to take a look at failed logins over the ssh so that I could show a few of my coworkers why that machine doesn't allow for password-based logins, and so I try to use variant #1 and get this:
grep: /var/log/auth.log: Permission denied
Nothing surprising there. Now, I could sudo chmod +r
, but there's probably a good reason why that log has its permissions set that way by default and it's not the best practice to go changing permissions without thinking about it first. So my next option is to use sudo
for examining the log. If I use sudo grep 'pattern' /path/to/log
, then grep
is now running as root. grep
is a fairly complicated piece of code, and there are so many ways to screw up the handling of regular expressions. Now if sudo cat /var/log/auth.log | grep 'pattern'
, then only cat
, a much simpler program, is running as root. I suppose I could also do this with input redirection, but I can never remember how to do it with sudo
. The cat
way has another advantage: when I get the permission error, it's pretty easy to press the up error, Ctrl+a and type sudo
. Easy peasy.
Now imagine, we have a relative newbie, just getting the hang of using grep
, awk
and the rest of the family, but still not 100% on the finer details of good practice. He knows that sudo
makes him a god for a single command and that he shouldn't use it too lightly, but he also knows that there are a lot of little tasks where he still has to sudo
up, e.g. all the package managers on the most popular distros. So he's gotten into the habit of automatically sudo
ing up whenever some vaguely system-administration related task gives him a permission error. So,one day he comes across the recommendation to check his /var/log/auth.log
for brute force attacks. He tries grep
as a normal user, but gets the permission error and immediately tries it again with sudo
. If he's using variant #1, then he just ran grep
(or perhaps an even more complicated piece of code) as root. If he goes with the cat
variant, then only cat
gets promoted to root. And let's not even consider the idea of issuing blanket advice to just sudo chmod +r
in such cases! Next thing you know, he'll be adding +w
to system configuration files.
Long story short: leaving the cat
in doesn't hurt; the performance penalty is trivial, especially on modern hardware; it occasionally makes things more secure; it potentially makes a line more readable (left to right in the direction of the pipe flow, fewer positional arguments, ability to change out intervening elements easily even when they take their arguments in a different order). Leave the cat
in and stop spawning useless mental processes thinking about it -- your mind is far worse at fork()
ing than your computer!
grep <pattern> <file>
if your <file> is an MVS dataset. You have to usecat "//'MVS.DATASET'" | grep <pattern>
if you want to grep a dataset.