In Part 2 of this series, I summarized the concepts and commands covered in Learning the Shell, Sections 5 through 8, from William Shotts’ online version of The Linux Command Line. In a follow-up post, I revisited two key principles from that week’s study (relative path directory references and globbing) as part of my Sunday review.
Today, I’m taking a closer look at two more foundational concepts: standard input, standard output, and how they interact with redirection. While I’m eager to move on to Sections 9 and 10, and eventually into Writing Shell Scripts, these topics feel like essential building blocks that will carry over into scripting and beyond. I want to make sure I’ve consolidated my understanding, so I’ll walk through some hands-on examples and share what I’ve learned.
Standard Input (stdin) and Standard Output (stdout)
I’ve found it useful to think of stdin and stdout as referring to the respective direction of data relative to a command. What I mean by this is that stdin flows into a command and stdout flows out of a command.
This is easy enough to understand when working with commands that read directly from standard input. For example, if I type the cat command and press Enter:

The terminal just sits there, waiting. That’s because cat is now listening for input from stdin, which by default is my keyboard. If I then type:
A new life awaits you in the Off-world colonies!

And press Enter again, that line flows into the cat command via stdin, and then immediately flows out via stdout, right back to the screen.

It will keep doing this until I signal the end of the input by pressing Ctrl + D

This interaction makes the flow of data into and out of a command feel very tangible. It’s a simple way to see stdin and stdout in action.
Redirecting stdout to a file
echo "What was said was for you, and you alone." > output.txt

The echo command sends my text to stdout, and the shell operator > redirects stdout to output.txt.
To confirm the file contains the redirected output, I can run:
cat output.txt

I can also run the ls command to list the contents of my present working directory and confirm that output.txt was written there.

Redirecting stdin from a file
cat < output.txt

Instead of typing input manually, cat reads from stdin, which is redirected from output.txt.

Using a pipeline (stdout to stdin)
ls /etc | grep "ssh"

ls lists the contents of the /etc directory and sends the result to stdout. That output is then piped into the stdin of the grep command, which filters for lines containing “ssh.”

If I run ls /etc without piping the grep command:

You can see that there are are lots of files and directories in that location.

Being able to redirect the standard output of the ls command so that it flows into the standard input of the grep command like this is super helpful. It saves me from having to scroll through the entire contents of the /etc directory to find what I’m looking for (and hoping I don’t miss it).
Combining stdin and stdout redirection
sort < output.txt > sorted.txt

In this example, the sort command reads from stdin, which is redirected from the contents of output.txt. It then writes the sorted result to stdout, which is redirected to a new file called sorted.txt.
To verify the result, I can run:
cat sorted.txt

This shows the sorted contents, confirming that both the input and output redirection worked as expected.
I can also run the ls command to see there is a new file in the working directory named sorted.txt.

Grasping stdin and stdout has unlocked a new level of control over the command line for me. These streams are the invisible threads that tie together powerful command-line workflows.
