The Terminal

What is it? #

The terminal is a window into a shell. The shell — usually bash or zsh — reads what you type, runs it, and shows you the result.

Its power comes from three things: composing commands with pipes, redirecting input and output, and controlling how commands run.

Everything a command produces goes to one of two streams: standard output for normal results, and standard error for problems. They can be redirected separately, which is why a command can print errors to your screen while writing results to a file.

Knowing a handful of shortcuts and control operators makes the difference between fighting the terminal and working comfortably in it.

Think of it like this #

A conveyor belt system. Each machine takes something in, does one job, and passes it along.

Redirection is choosing where the belt ends: into a bin, into a box you keep, or into another machine.

Simple example #

You need to find the twenty most frequent IP addresses in a large access log, save the result to a file, and do it without waiting at the terminal for ten minutes.

Code #

# Composing a real pipeline
awk '{print $1}' /var/log/nginx/access.log \
  | sort \
  | uniq -c \
  | sort -rn \
  | head -20 \
  > top-ips.txt
# extract column 1 | sort | count duplicates | sort by count | take 20 | save

# Redirection
command > out.txt        # stdout to a file, overwriting
command >> out.txt       # append instead
command 2> errors.txt    # stderr only
command > all.txt 2>&1   # both streams into one file
command 2>/dev/null      # discard errors
command < input.txt      # feed a file in as stdin

# Chaining
command1 && command2     # run command2 only if command1 succeeded
command1 || command2     # run command2 only if command1 failed
command1 ; command2      # run both regardless

# Long-running commands
./import.sh &            # run in the background
jobs                     # list background jobs of this shell
fg %1                    # bring job 1 back to the foreground
Ctrl+Z                   # suspend the current command
Ctrl+C                   # stop the current command

nohup ./import.sh &      # keeps running after you log out
tmux new -s import       # better: a session you can detach and reattach
# Ctrl+b then d to detach, tmux attach -t import to return

Shortcuts worth learning

Ctrl+R      search your command history
Ctrl+A/E    jump to the start / end of the line
Ctrl+W      delete the previous word
Ctrl+U      clear the line
Tab         complete a command, path or option
!!          the previous command, e.g. sudo !!
!$          the last argument of the previous command

How it works #

The pipeline reads left to right. awk '{print $1}' prints the first whitespace-separated field of each line, which in an access log is the client IP. sort groups identical lines together, which uniq -c needs in order to count them. sort -rn then orders by that count numerically, highest first, and head -20 keeps the top twenty.

uniq only collapses adjacent duplicates, which is why the first sort is required. Forgetting it produces wrong counts silently.

> sends standard output to a file, replacing it. >> appends. 2> handles standard error separately, and 2>&1 merges error into output so both land in the same place.

&& and || branch on the exit code: zero means success. This is why make build && ./deploy.sh is safe — the deploy only runs if the build worked.

Running a command with & puts it in the background, but it still belongs to your shell session and dies when you disconnect. nohup detaches it from that, and tmux is better still: a persistent session you can leave and come back to, with your command still running and its output intact.

For anything long-running on a remote server, tmux is the practical answer. A dropped connection during a migration is otherwise an interrupted migration.

Real-world use #

Log analysis pipelines like the one above are a daily tool. Finding the slowest endpoints, counting error codes, extracting user IDs from a log — all of it is a few piped commands.

Redirection matters in scripts and cron jobs. A cron job that does not redirect its output either emails it or loses it, and >> /var/log/myjob.log 2>&1 is the usual pattern.

Exit codes are what CI pipelines check. A script that fails but exits zero will be treated as successful, which is a common and quiet bug.

The habit of using tmux on servers saves real work. Deployments, migrations, backups and long imports should never depend on your SSH connection staying alive.

Discarding errors with 2>/dev/null is convenient and occasionally dangerous — it hides problems you might want to know about.

Common mistakes #

• Using uniq without sorting first, producing wrong counts.
• Redirecting with > when you meant >>, overwriting a file.
• Running a long command over SSH without tmux, losing it when the connection drops.
• Forgetting that 2> and > are separate streams, so errors still appear on screen.
• Suppressing errors with 2>/dev/null and then wondering why nothing seems wrong.

Practice #

Take any log file and build a pipeline that finds the ten most common values in one column, saving the result to a file while discarding errors. Then start a long-running command inside tmux, detach, reconnect and confirm it is still running.