1. Definition / Conclusion

In Linux, < is a redirection syntax that connects the contents of a file to a program’s standard input (stdin).
Many people see < and interpret it simply as “a syntax for reading a file,” but that is not accurate. The essence of < is not about directly handling a file. The key point is that it changes the source of the program’s default input channel to a file.

A program can typically receive input in multiple ways. A user can type input directly via the keyboard, a file name can be passed as an argument so the program opens it itself, or the output of another program can be passed through a pipe. Among these, stdin is the “standard channel through which input is received.” < is the syntax that changes the source of this channel. In other words, it creates a structure where input that would normally be typed directly in the terminal is instead supplied by a file.

For example, when you see cat < input.txt, it may appear on the surface that cat is reading a file. However, the actual structure is different. cat is originally a program that reads from stdin, and since the shell connects stdin to input.txt before execution, cat simply reads from stdin as usual. From the program’s perspective, the important point is not “opening a file directly,” but rather “reading data from a familiar input channel.”

Once you understand this structure, it becomes clear why cat input.txt and cat < input.txt may produce similar results but operate differently internally. The former is a method where the program receives a file name as an argument and opens the file itself, while the latter is a method where the shell first changes the input channel to a file and then executes the program. Although the visible result may look similar, the source of input and the entity responsible for handling it are fundamentally different.

The core idea can be summarized in one sentence:

< is not a syntax for directly reading a file, but a syntax that changes the source of a program’s standard input (stdin) to a file.

Understanding this concept clearly also helps distinguish the difference between < and |, as well as between passing a file as an argument and streaming data through stdin. Furthermore, it naturally connects to concepts such as here-doc, here-string, tee, file descriptor 0, and even the internal mechanism based on dup2(). Ultimately, < is not just a simple symbol, but a core syntax that completes the input side of Linux’s I/O structure.

2. Key Summary

stdin is the standard channel through which a program receives input.
In a typical terminal environment, this channel is connected to the keyboard, so user input flows directly into the program. However, this connection is not fixed. The shell can change the source of stdin before executing a program, and < is the most representative input redirection syntax used for this purpose.

In other words, < is a way to feed a file into a program as its input.
The important point here is that the program does not receive a file name; instead, the file’s contents are delivered through stdin. Therefore, < is different from passing a file as an argument, and it is also different from using a pipe.

There are three key distinctions that must be clearly understood in this context.

First, the difference between keyboard input and <.
When a program reads from stdin, that stdin is typically connected to terminal input. However, when you add < file.txt, the input is no longer coming from the keyboard but from the file. In other words, the input channel remains the same, but the source of the input changes.

Second, the difference between < and a pipe (|).
Both appear to fill a program’s stdin, but < connects a file to stdin, whereas | connects another program’s stdout to stdin. The former is a static input source, while the latter is a dynamic data flow from another running process.

Third, the difference between passing a file as an argument and using <.
command file.txt means the program receives the file name as an argument and opens it itself. In contrast, command < file.txt means the shell first connects stdin to the file and then executes the program. As a result, even when handling the same data, the entity responsible for processing and the output format may differ.

The distinctions can be summarized as follows:

# Keyboard input
cat

# File connected to stdin
cat < input.txt

# File passed as an argument
cat input.txt

# File becomes stdin
sort < names.txt

# Another program's output becomes stdin
cat names.txt | sort

# File passed as an argument
wc -l input.txt

# File content passed through stdin
wc -l < input.txt

If you fail to understand these differences, you will end up treating < as just a “file reading symbol.”
However, Linux redirection is not that simple. If > changes the direction of output, then < changes the source of input. Only by understanding both can you fully grasp the complete I/O structure.

3. Why Is It Necessary

Programs do not always process data by receiving file names as arguments.
In fact, a key characteristic of Unix-like tools is that they abstract the input source. From the program’s perspective, what matters is not where the data comes from, but whether it arrives through stdin. This design allows the same program to handle keyboard input, file input, or input from another program’s output seamlessly.

For example, tools like cat, sort, wc, and grep work well with stdin-based input. The importance of this lies in the fact that changing the input source does not require changing the program itself. The program simply reads from stdin, and whether the input comes from the keyboard, a file, or a pipe is handled entirely by the shell. In other words, data processing logic is separated from the input source, which is a fundamental principle of Unix tool design.

The second reason is automation.
Tasks that require manual keyboard input are difficult to repeat. While it may be possible to execute them once, it becomes inefficient when you need to test with the same input multiple times, run batch jobs, or reproduce an issue. However, if input is stored in a file and fed using <, the situation changes. You can reproduce the exact same input, run it repeatedly, and eliminate the need for manual intervention.

./app < sample-input.txt

With just this one line, you can enable various practical patterns such as automated test input, algorithm problem input reproduction, initial configuration input, and SQL batch execution. By externalizing input into a file and having the program read only from stdin, both reproducibility and automation improve significantly.

The third reason is structural understanding.
Many people first learn redirection on the output side because symbols like >, >>, 2>, and 2>&1 are more visible. However, understanding only output redirection means you are only seeing half of the I/O structure. Redirection is not just about changing where results are sent; it is about reconfiguring the connection points of both input and output. Therefore, understanding < allows concepts like stdin, stdout, stderr, pipes, /dev/null, and tee to come together into a unified structure.

Ultimately, the reason < is necessary is simple.
It allows the source of a program’s input to be changed flexibly. And this flexibility enables automation, reproducibility, composability, and tool reusability. The strength of the Linux command line does not come from individual commands being sophisticated, but from how well these connection mechanisms are designed.

4. Examples

Example 1. Supplying a file to stdin instead of keyboard input

The most basic example is cat.
cat can receive a file name as an argument, but if no argument is given, it reads from stdin. This property makes it ideal for explaining <.

cat < input.txt

The result is simple.
The contents of input.txt are displayed on the screen.

Why does this happen?
Since cat has no arguments, it would normally wait for keyboard input. However, because the shell connects stdin to input.txt before execution, cat no longer waits for keyboard input and instead reads the file contents from stdin. In other words, cat is not opening the file directly; it is simply reading from stdin.

This example is useful because it clearly demonstrates the essence of <.
< does not mean “display a file on the screen,” but rather “the file becomes the program’s input.”

Example 2. Same result, different structure

cat input.txt and cat < input.txt produce almost identical output.

cat input.txt
cat < input.txt

Both display the contents of input.txt.
However, their internal structure is completely different.

In the first command, cat receives input.txt as an argument and directly opens and reads the file.
In the second command, cat receives no file name. The shell first connects stdin to input.txt, and then executes cat. As a result, cat reads from stdin, not from a file.

The difference can be summarized as follows:

# Program receives a file name
cat input.txt

# Shell connects stdin to a file
cat < input.txt

This distinction is important to avoid misunderstanding <.
Many beginner explanations simply say the two commands are “almost the same,” which is correct in terms of output but incorrect in terms of structure. In Linux, what matters is not just the result, but who opens what, and what is connected to what. If you miss this point, it becomes difficult to properly understand pipes, tee, dup2, and file descriptor redirection.

Example 3. Feeding input to stdin-based programs

wc -l is a command that counts lines. It can accept a file name as an argument or read input from stdin.

wc -l input.txt
wc -l < input.txt

These two may look similar, but their output can differ.
The first usually prints the line count along with the file name, for example:

42 input.txt

The second processes only the raw data coming through stdin, so it does not know the file name. Therefore, it typically outputs only the number:

42

Why does this happen?
In the first case, wc directly opens the file input.txt, so it knows which file it processed. In the second case, it simply reads a stream of bytes from stdin. Even though the data is the same, the source information is not passed to the program.

This example is also meaningful in practice.
In pipelines, the raw data stream is often more important than file names. Using < can simplify output format or make it more consistent with other stdin-based tools.

Example 4. Preparing multi-line input in advance

Input redirection is especially powerful for automating interactive input.
For example, consider a Python script that reads from standard input:

python3 script.py < input.txt

This allows the contents of input.txt to be fed into the program automatically, without manual typing.

The same pattern is commonly used for SQL execution:

mysql -u user -p dbname < init.sql

This command supplies the SQL statements inside init.sql to the mysql client via stdin.
In other words, the client does not interpret the file as an argument; instead, the SQL text is passed as an input stream.

This pattern is important because of automation and reproducibility.
Many tasks can be executed manually by typing input, but in practice, you often need to run the same input across different environments, automate it in CI/CD, or reproduce issues. In such cases, < converts “manual input” into “reproducible file-based input.”

5. Difference Between < and Pipe (|)

< and | are often confused because both supply input to a program’s stdin.
In many cases, they even produce similar results.

sort < names.txt
cat names.txt | sort

Both commands can output the sorted contents of names.txt.
However, their structures are different.

In the first command, the stdin of sort is directly connected to the file names.txt.
That is, the input source is the file.

In the second command, cat reads names.txt and outputs it to stdout, and that stdout is connected to the stdin of sort through a pipe.
That is, the input source is another program’s output, not the file itself.

Structurally, the difference looks like this:

sort < names.txt
-> names.txt ----> stdin(sort)

cat names.txt | sort
-> names.txt -> cat stdout ----> stdin(sort)

This difference is not just about performance, but about meaning.
< connects a static input source (a file) to stdin, while | connects processes together. The former defines the starting point of input, while the latter defines the processing flow.

Therefore, when dealing with simple file input, < is more direct:

sort < raw.txt | uniq

This command connects a file to stdin to define the start of a pipeline, and then uses pipes to connect subsequent processing steps. This structure shows that < and | are not competing concepts but serve different roles. < defines the input source, and | connects the processing flow.

In other words, < and | should not be considered the same.
Both affect stdin, but they connect different sources to it. Understanding this distinction is essential for designing pipelines and understanding redirection structures.

6. Difference Between Passing a File as an Argument and Using <

This is one of the most important comparisons in this article.
Because the visible results can be similar, it is one of the most commonly misunderstood aspects.

Consider the following two commands:

grep ERROR log.txt
grep ERROR < log.txt

Both appear to search for lines containing ERROR in log.txt.
The results may even look similar. However, the structure is different.

In the first case, grep receives log.txt as an argument, so it directly opens and searches the file.
In the second case, the shell connects stdin to log.txt and then runs grep ERROR. As a result, grep searches the text coming from stdin.

This difference can be summarized as follows:

# Program receives a file name
command file.txt

# Program receives only stdin
command < file.txt

An important point is that not all programs work well with stdin.
Some tools are optimized to process files directly through arguments, while others support stdin but may behave differently or produce different output formats when given file names. Some programs may not read stdin at all and instead expect only options or arguments.

For example, wc -l input.txt and wc -l < input.txt may produce different output formats. Some CLI tools can process multiple files when given as arguments but cannot do so when using stdin. Conversely, some filter-type tools are more naturally used with stdin.

In other words, passing a file as an argument and using < are not interchangeable—they are two fundamentally different input methods.
One is a method where the program directly handles a file, and the other is a method where the program processes only an input stream. Which one is appropriate depends on the design of the program and the intended use case.

7. Practical Applications

1) Reproducing batch input

In practice, being able to replay the same input is extremely important.
To analyze the cause of an issue, you need to reproduce the input at the time it occurred, and for test automation, manual input is not an option. In this context, < becomes the simplest and most powerful tool.

./app < sample-input.txt

With this approach, you can store what was previously typed manually into a file and execute it repeatedly under the same conditions.
This is especially useful for algorithm testing, interactive CLI debugging, batch job reproduction, and re-running failure scenarios.

The key is to externalize the input.
Once input becomes a file, it can be version-controlled, managed as a test dataset, and easily moved across environments. Since the program only needs to read stdin, the structure becomes simpler and operations become more predictable.

2) Automating SQL / script execution

Many CLI tools accept input through stdin.
Because of this, a common pattern is to write commands into a file and feed them using <.

mysql -u user -p mydb < schema.sql

sqlite3 test.db < init.sql

The advantages of this approach are clear.
Operators do not need to manually paste SQL commands into the console, execution history can be preserved in files, and the same script can be applied repeatedly across different environments. This pattern is especially common for initial schema setup, test data loading, and batch SQL execution.

The important point here is that the data is provided through a file as input.
Even if a tool does not support file arguments directly, as long as it reads from stdin, < is sufficient for automation.

3) Defining the starting point of a pipeline

Linux pipelines often appear to start from the output of another program, but in practice, they frequently start from a file. In such cases, < naturally defines the starting point of the pipeline.

sort < raw.txt | uniq

This command works as follows:

  • raw.txt becomes the stdin of sort
  • The stdout of sort becomes the stdin of uniq

In other words, < and | can be used together effectively.
In practice, this combination is quite natural: use a file as input for the first filter, then connect subsequent processing stages with pipes. From this perspective, < is not the opposite of a pipeline, but rather a tool for defining the input source at the front of a pipeline.

4) Automating interactive workflows

Some programs require multiple lines of input after execution.
Typing these manually may be feasible once or twice, but it is not suitable for repeated execution. In such cases, you can store the responses in a file and supply them using < to automate the input process.

python3 wizard.py < answers.txt

This pattern is commonly used for installation wizards, simple configuration tools, educational input/output programs, and internal operational CLIs. While more complex interactions may require tools like expect, simple input flows can often be automated entirely with <.

In other words, < is not just a syntax—it is a way to transform manual input into file-based execution.
This difference has a significant impact on automation and reproducibility.

8. Common Mistakes

Mistake 1. Treating < as a “file reading syntax”

This is the most common misunderstanding.
When people see command < file.txt, they often think, “this command reads file.txt.” However, this interpretation is only partially correct and structurally misleading.

In reality, < does not make the program open the file directly.
Instead, the shell first connects stdin to file.txt and then executes the program. Therefore, the program does not receive a file name—it simply reads from stdin.

If you miss this distinction, you will not be able to differentiate between passing a file as an argument and stdin redirection.
As a result, you will struggle to explain why cat file.txt vs cat < file.txt, or grep ERROR log.txt vs grep ERROR < log.txt, behave differently at a structural level.

The correct understanding is clear:

< is not a syntax for making a program read a file directly, but a syntax for changing the source of standard input to a file.

Mistake 2. Treating < and pipe as the same

The following two commands may produce similar results:

sort < file.txt
cat file.txt | sort

Because of this, many people treat them as identical.
However, < connects a file to stdin, while | connects another process’s stdout to stdin.

Ignoring this difference makes it difficult to understand data flow and process structure.
Especially in longer pipelines, whether the input originates from a file or from another process becomes an important distinction.

In short, < and | may produce similar results, but they are not the same concept.
The former is file-based input connection, while the latter is process-to-process connection.

Mistake 3. Assuming all programs read from stdin

Sometimes, adding < file.txt does not produce the expected behavior.
In such cases, it is easy to assume something is wrong with the syntax, but the real issue may be that the program does not support stdin input.

Some programs are designed to accept input only through file arguments or specific options.
In such cases, using < may have no effect or produce entirely different behavior.

Therefore, when using <, you must understand the input model of the tool.
Whether it is stdin-based, argument-based, or option-based varies from program to program. Even if Linux commands look similar, their input design can differ significantly.

Mistake 4. Assuming cat < file is always better

From an explanatory perspective, cat < file is a good example because it clearly demonstrates the nature of stdin redirection. However, in practice, it is not always the better choice.

If you simply want to view a file, cat file is more direct and readable.
If a program naturally supports file arguments, there is often no need to use <.

In other words, < is not a superior syntax—it is a different syntax with a different meaning.
It should be used when you want to change the input channel, not as a universal replacement for file arguments.

Mistake 5. Thinking input and output redirection are just opposites

Treating < and > as merely left-right opposites can lead to misunderstandings.
While they belong to the same family of syntax, they operate on different targets.

  • < handles stdin, which is file descriptor 0
  • > handles stdout, which is file descriptor 1
  • 2> handles stderr, which is file descriptor 2

So this is not simply about direction—it is about handling different channels.
Understanding this distinction is essential to correctly grasp concepts like 2>&1, /dev/null, <, and | within a unified file descriptor structure.

To fully understand <, it should be considered alongside several related concepts.

First, there is stdin / stdout / stderr.
These represent standard input, standard output, and standard error, which are the fundamental I/O channels of Linux programs. < specifically operates on stdin.

Next, there is pipe (|).
A pipe changes the source of stdin from a file to another process. While it operates in the same domain as <, the connection target is different.

There are also here-doc and here-string.
These are methods of supplying multiple lines of text or short strings to stdin without using a file. Ultimately, they address the same problem: how to provide input to a program.

Another concept is tee, which is commonly associated with stdout branching. However, when explaining the overall I/O structure, it is helpful to consider it together. Understanding where input comes from and where output goes makes the role of tee much clearer.

Finally, there are file descriptors 0, 1, and 2.
< ultimately operates on file descriptor 0, which is stdin. Viewing redirection from this perspective clarifies that it is not just syntax, but a mechanism for reassigning file descriptor connections.

10. Deeper Dive

At a surface level, < file.txt may look like just another piece of syntax.
However, internally, it is closer to the shell connecting stdin (FD 0) to a file before executing the program.

Conceptually, it resembles the following:

int fd = open("input.txt", O_RDONLY);
dup2(fd, 0);
close(fd);
execvp(...);

The meaning of this code is clear:

  1. Open input.txt in read-only mode
  2. Duplicate that file descriptor onto file descriptor 0 (stdin)
  3. Close the original file descriptor
  4. Execute the program in that state

As a result, the executed program does not receive a file name.
It simply reads from stdin as usual, but that stdin happens to be connected to a file.

This point is important because it shows that the essence of < is “reassigning the input channel at the shell level.”
The program does not need to explicitly recognize the file. As long as it can read from stdin, it will work in the same way. This is the core mechanism that enables the composability of Unix tools.

From this perspective, > and 2> also become naturally connected.
> changes file descriptor 1, 2> changes file descriptor 2, and < changes file descriptor 0. In other words, redirection is not about memorizing symbols, but about reconfiguring file descriptor connections.

There is no need to go too far into the full process execution model here.
The key takeaway is that the shell modifies stdin before execution. That alone is sufficient to understand < as a structural mechanism rather than just syntax.

11. Summary

In Linux, < is an input redirection syntax that connects a file’s contents to stdin.
The important point is that it does not directly read a file, but instead changes the source of the program’s input channel.

Once this perspective is established, several distinctions become clear.
command file.txt is a method where the program receives a file name, while command < file.txt is a method where the program receives data through stdin.
Similarly, < file.txt connects a file to stdin, while cmd1 | cmd2 connects another program’s stdout to stdin.

In practice, < is highly useful.
It underpins patterns such as input automation, test reproducibility, SQL execution, batch input feeding, and defining the starting point of pipelines. In particular, it is a powerful way to convert manual input into file-based execution.

The essential rules to remember in real-world usage are clear:

# Pass a file as an argument
command file.txt

# Pass file content through stdin
command < file.txt

And the most important statement is this:

< is not a syntax for reading a file directly. It is a syntax that changes the source of a program’s standard input (stdin).

With this understanding, the Linux I/O structure becomes much simpler.
Programs read from stdin and write to stdout and stderr, while the shell modifies these connections using <, >, 2>, and |. If you already understand output redirection, then < completes the picture of the entire I/O model.