How to learn the Linux command line

You learn what a process is, what standard input, output and error are, and how redirection changes them. This sits first because every later stage assumes you can trace where bytes go. Without this, pipes look like magic.

• Processes and the PID
• Standard input (fd 0)
• Standard output (fd 1)
• Standard error (fd 2)
• Redirection with > and >>
• Redirecting stderr with 2>
• Combining streams with 2>&1
• The /dev/null device

You can now: Explain, without looking it up, what happens to stdout and stderr when you run `command > file 2>&1` and why the order of the redirections matters.

Pipes connect one process's stdout to another's stdin. Here you start treating text as a data stream rather than as messages. This stage sits second because it builds directly on the file descriptor model and makes all later filtering commands meaningful.

• The pipe operator |
• Why pipelines are not just command chaining
• Exit statuses and $?
• The head and tail commands
• The wc command
• The sort command
• The uniq command
• Text encoding and line endings

You can now: Count the number of unique lines in a 10,000-line log file using a single pipeline and explain which command failed if the count is wrong.

Grep and find are where the shell becomes a tool for locating things across a filesystem. They sit here because they require fluency with pipes, patterns and exit statuses, and because they are the first commands where the flags genuinely change behaviour.

• grep basics: plain strings
• Regular expressions in grep
• grep flags: -i, -v, -r, -n, -l
• The find command syntax
• find predicates: -name, -type, -size, -mtime
• Combining find with -exec
• xargs and argument limits
• Escaping and quoting in search patterns

You can now: Find every .log file modified in the last 7 days under /var that contains the string 'error' and print the matching lines with filenames, in one command.

sed and awk are the two tools that turn the shell from a query interface into a transformation engine. They come after grep and find because you need to have already internalised the idea that text is data and that every command is a filter.

• sed basics: substitution with s///
• sed addresses and ranges
• sed hold space and pattern space
• awk field processing with $1, $2, etc.
• awk patterns and actions
• awk built-in variables: NR, NF, FS
• Simple awk scripts with BEGIN and END
• When to use sed and when to use awk

You can now: Take an Apache access log and produce a sorted list of the top 10 IP addresses by request count, using only grep, sed, awk, sort and uniq.

A script is just a sequence of commands with variables, conditionals and loops. This stage appears after the filtering tools because you cannot write a useful script until you can compose commands fluently, and because scripts are where the model of exit statuses becomes explicit.

• Shebang and script permissions
• Variables and quoting rules
• Exit statuses and if statements
• Test operators: [ ] and [[ ]]
• Loops: for and while
• Function definitions
• Positional parameters and $@
• Reading input with read

You can now: Write a script that takes a directory as an argument, finds all files larger than 100 MB, prints their sizes and names sorted by size, and exits with a non-zero status if no such files exist.

The final layer is control: running processes in the background, killing them safely, and understanding file permissions and ownership. This comes last because it is the layer most often needed when things go wrong, and it builds on every earlier stage's understanding of how the shell launches work.

• Foreground and background jobs
• Job control: Ctrl-Z, bg, fg
• Signals: kill, kill -9, SIGTERM
• The ps command and its output
• The top and htop commands
• File permissions: rwx and octal
• chmod, chown, and umask
• Process substitution and named pipes

You can now: Start a long-running command, suspend it, move it to the background, list it with jobs, and then terminate it cleanly with a signal other than SIGKILL.

The last stage consolidates everything into a working environment: your own dotfiles, aliases, and configuration. It sits at the end because it is about automation of the habits you have built, not about learning new commands.

• Shell configuration files: .bashrc, .profile
• Environment variables and PATH
• Aliases and functions
• Command history and Ctrl-R
• Tab completion and its limits
• Brace expansion and globbing
• Combining everything in a small project

You can now: Configure your shell so that a new terminal automatically sets a custom PATH, defines three aliases, and has a prompt showing the current git branch, then explain what breaks if you move the aliases to .profile instead of .bashrc.