Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I used the following two commands to produce the same results:-

[root@localhost ~]# grep line comments
The line should start with a single quote to comment in VB scripting.
Double slashes in the beginning of the line for single line comment in C.
[root@localhost ~]#

[root@localhost ~]# grep line <comments
The line should start with a single quote to comment in VB scripting.
Double slashes in the beginning of the line for single line comment in C.
[root@localhost ~]#

Could any please explain to me any pros/cons if any of these 2 approaches over each other.

share|improve this question
up vote 12 down vote accepted

From the man grep page (on Debian):


   grep  searches the named input FILEs (or standard input if no files are
   named, or if a single hyphen-minus (-) is given as file name) for lines
   containing  a  match to the given PATTERN.  By default, grep prints the
   matching lines.

In the first case, grep opens the file, in the second the shell opens the file and assigns it to the standard input of grep, and grep not being passed any file name argument assumes it needs to grep its standard input.

Pros of 1:

  • grep can grep more than one file.
  • grep can display the file name where each occurrence of line is found

Pros of 2:

  • If the file can't be opened, the shell returns an error which will include more relevant information (like line number in the script) and in a more consistent way (if you let the shell open files for other commands as well) than when grep opens it. And if the file can't be opened, grep is not even called (which for some commands, maybe not grep can make a big difference).
  • in grep x < in > out, if in can't be open, out won't be created or truncated.
  • There's no problem with some files with unusual names (like - or file names starting with -).
share|improve this answer
+1, for the nice explanation. I have one doubt: in the 2nd case when the shell opens the file does it pass the opened file contents to the standard input (keyboard) ?? ( I got confused with the term 'standard input of grep'). – Ankit Apr 1 '13 at 16:09
@Ankit, stdin is where applications read their input by default, the file descriptor 0. When in a terminal, fd 0 is opened from reading on the terminal device (something like /dev/ttyxx or /dev/pts/n). That's how they end up getting what you type on the keyboard. Shell redirection of a command's stdin just opens the fd 0 to some other file before executing the command. – Stéphane Chazelas Apr 1 '13 at 18:58

The answer by StephaneChazelas covers grep(1), and most Unix lineage commands work that way, but not all. It is standard to read either from standard input (from the keyboard, from a file redirected via < file, or from the output piped by another command, stupid example ls * | grep '^ab*c$'), or from the file(s) given as arguments, like grep comment file1 file2 file3. Some commands use the convention there that the file named - is standard input, so you can say make-middle | cat head - tail to get a stream with head, whatever gen-middle generates, followed by tail. This is by design, to give flexibility in the use of the commands.

Which is better? As long as it works, cmd file is shorter than cmd < file; there could be a tiny difference in time between the shell doing the file frobbing (<) and the command doing it by itself, but probably unnoticeable unless you do nothing else all day long. It will depend on considerations like the pros mentioned in Stephane's answer.

share|improve this answer
cmd file is not shorter than cmd<file though. – Stéphane Chazelas Feb 2 at 13:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.