What is a good use of input redirection "<"?


The example given for the use of input redirection here:

cat < lakes.txt

Doesn’t seem particularly helpful since is does the same thing as cat lakes.txt. Please share a case where the use of input redirection, <, makes an important contribution.


There’s redundancy in the above example because most of the built-in functions that we would want to use in redirecting input, cat and sort for example, already directly accept files as input. So we won’t get any added benefit from using <. However, if a function is designed to simply read from the standard input, then < helps us out.

Let me be more explicit. Suppose you write a function which expects some user input. The typical ways that we do this in a programming language reads directly from stdin. It’s tedious to test or interface with this function completely through the standard input. So we may either write a collection of test input in a file or aggregate real input to this program in a file, prior to calling the function. How do we then make the program believe that it’s reading from stdin while it’s actually reading from the file we made? We accomplish this by using < where on the left side, we have our (executable) program and on the right we have the file we created. In this way, we pass all of the input to the function at once. This proves to be extremely handy in testing and interacting with programs in the command line.


Hello CC Moderator,

It is great that this question is addressed in FAQ section, however the part after

Let me be more explicit …

did not make any sense to me.
I am not sure whether this is because it is addressed to the audience, who is more advanced in Web Development or Computer Science.

Can a simpler explanation/example be provided on relevance of the use of < command?
Thank you!


Hi zachg131,

I’m not an experienced developer, just like you, and I didn’t get the difference between those two commands. So I tried to google this topic and here’s what I found. It seems this explanation makes sense:

In the first case, cat opens the file, and in the second case, the shell opens the file, passing it as cat’s standard input.

Try to type “cat file.txt” command and point it out to the nonexisting file. You’ll get an error message from cat:

cat: test.txt: No such file or directory

Then try to type “cat < file.txt” command and point it out to the nonexisting file. You’ll get an error message from bash:

-bash: text.txt: No such file or directory

Basically, if I understood it right, this means that in the first case, cat opens the file, in the second case bash opens the file first and then passes the result to cat.

Here are some more details:

Technically, they could have different effects. For instance, it would be possible to have a shell implementation that was more (or less) privileged than the cat program. For that scenario, one might fail to open the file, while the other could.

That is not the usual scenario, but mentioned to point out that the shell and cat are not the same program.

Hope this helps.


Hi zachg131,
I may know what you mean.
You want to know why do we use ‘<’ if we can cat xxx.txt (rather than
cat < xxx.txt).
The scenario which advisor mentioned is like this:
When you ‘cat xxx.txt’ with content 1, 2, 3, it prints 1, 2, 3
If you have a file abc with a function “def abc(x, y, z)” and you want to test the function with inputs 1, 2, 3 (pass 1, 2, 3 values to variables x, y, z ) that are stored in xxx.txt. you can use “cat abc < xxx.txt” instead of type 1, 2, 3. ( I am also a beginner so I don’t know what usually is an executable programme`s extension name and how exactly to test it.)


To expatiate, and as hinted in the lessons, commands (that take in user input/parameters) in bash typically read from a standard input (think of this as a formatted input that a command can easily process to give an answer - essentially, when one types an input to a command, that input gets formatted to a standard form, and then processed by the command. For example, in ‘cat volcanoes.txt’, ‘volcanoes.txt’ is formatted to a standard form for the cat command to process).

The results of any command are then pushed to either a standard output or standard error. The workings of showing the result are just in the same vein, similar to as you have in reading from standard input.

As an aside, one of the the themes that makes computing technology very efficient is implementing interfaces that abstract the internal workings of a system, command, function but require standard interfaces. Bash adheres to this theme with the use of standard input, standard output, and standard error.

To the question at hand:

cat lakes.txt: typical use of the cat command.

cat < lakes.txt: here, ‘<’ redirects the file ‘lakes.txt’ to a standard input and then cat works on the standard input to output a similar result as we would have seen in the first case of ‘cat lakes.txt’.
As zjedwin alluded, this approach lends itself easily to scenarios where ‘lakes.txt’ isn’t a file but say a complex command or the result of a command. In such case the complex command is evaluated, its output is then redirected by ‘<’ as a standard input to the cat command. To achieve the same result with the first approach would require a complex syntax - which is undesirable in writing efficient programs.


I found some nice tutorial series here about terminalstrong text

hope this will be helpful.

1 Like

amazing explanation. thank you brother.

1 Like

Corey Schafer is a gifted teacher :+1:, much more talented than sadly many of the teachers at Codecademy (a great programmer does not necessarily make a great teacher - and vice versa). :pensive:

1 Like

This lesson talks about ‘wc’ command in CLI. And it says that it outputs number of lines, words and characters respectively. When I type - ‘wc continents.txt’, It outputs ‘8 9 69 continents.txt’. Why the file name is incuded in the output?

Hello @mauj_mishra!

The file name is included in the output by default. It can be helpful if you pass more than one argument to the wc command, meaning the number of lines, words, and/or characters is outputted for more than one file. See this article for more information.

I’m new to this too, and I agree this is a confusing example. Here’s how I understand it:

There are commands like “cat” that can take files as arguments. cat knows what to do if you give it a whole file, it prints the contents.

There are other commands that we haven’t learned yet, that only know what to do with a specific kind of input, like actual text, not a whole file. In that case, using command < file.txt lets the command line pull the text out of the file and feed it to the command instead of giving it the file itself.

This is WAY oversimplified, but if it helps, it’s like offering a kid a banana. Older kids can get the whole banana, peel it themselves, and eat the fruit. Younger kids can’t do the peel, and they need an adult to open it for them and hand them the fruit. In this example, we peeled a banana for a kid who is old enough to peel it themselves.


thanks for this explanation!!!