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

Question

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.

Answer

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.

39 Likes

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!

21 Likes

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.

26 Likes

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

12 Likes

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.

5 Likes

I found some nice tutorial series here about terminalstrong text

hope this will be helpful.