What’s the difference between providing input to a command via an argument to that command and providing input through a shell redirection operator?

Question

When I use my shell’s redirection operator to provide a (non-existent) filename to the grep command, the error message about that file not existing is displayed by my shell. But when I provide that same filename as an argument to the grep command, the corresponding error message is displayed by the grep command itself. Why is that?

Here’s a demonstration of what I’m talking about. When I run the command:

$ grep 'root' /etc/passw

I get the following error message:

grep: /etc/passw: No such file or directory

But when I run the command this way with shell redirection:

$ grep 'root' < /etc/passw

I instead get the following error message:

bash: /etc/passw: No such file or directory

What is the difference between these two methods of specifying the input filename, and is there any significance in having them behave this way?

Answer 1

In your first command ($ grep 'root' /etc/passw) you give argument/s to grep and it interprets it as file name and searches for it. It (grep) fails so communicates you what happened. It is grep that interprets your input and acts on it.

In your second command (grep 'root' < /etc/passw) you make shell (here: bash) to pipe /etc/passw to standard input of grep. It (bash) cannot find it so it communicates you that. Here, it is bash that interprets your input and acts on it.

Second command is conceptual equivalent to $ bash-cat /etc/passw | grep 'root' where bash-cat would operate as cat which prints given file on standard output. Then it would be redirected to grep.

$ bash-cat /etc/passw | grep 'root'

bash-cat: /etc/passw: No such file or directory

--

If you read about pipes you will understand. (Pipes: A Brief Introduction)

Answer 2

When using I/O redirection operators like this, the shell itself opens the file for the input to the command as stdin with O_RDONLY on fd0 which commands can read only from it, but when passing as an argument, it’s the command itself which handles opening the file.

So if you have a program — let's say awk — and use < redirection to pass the filename, and you try to print FILENAME for which file it's opened, it will get reported - (meaning that input is stdin); see the following output:

awk '{ print FILENAME }' --infile
--infile
awk '{ print FILENAME }' <--infile

Another advantage is that if a filename starts with a hyphen, the shell will handle it itself, but if you pass as an argument to the command — say grep — it will complain because it think it's an invalid option provided.

grep root --infile
grep: unrecognized option '--infile'
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.

Standard, standards-compliant commands use -- to avoid this error by telling the command it’s the end of its option-argument. You can also provide either the absolute path of file or a relative path with ./--infle, or you let the shell open it for the command by using command <--infile.

note: Use of <inputfile command is the same variant of the command <inputfile.

another advantage is if that file was not exist or shell failed to open it, then your command will not execute.

awk 'BEGIN{ print "ifrun" }' < non-existing_file
-bash: non-existing_file: No such file or directory
awk 'BEGIN{ print "ifrun" }' non-existing_file
ifrun