The semicolon: run commands in sequence

; - a hands-on Linux lab on a real virtual machine.

Put several commands on one line with the semicolon and the shell runs them left to right, no matter how each one turns out. You chain echoes, watch a chain survive a failure, and learn why silent commands in a chain still ran. All in the practice terminal.

Here is a small mystery to open on. In a moment you will type a single line, press Enter exactly once, and watch the shell run three separate commands, one after another, like dominoes falling.

So far you have run commands one at a time: type one, press Enter, wait, type the next. That works, but real work is a sequence. Back up a file, then compress it, then move it. Typing and waiting three separate times gets old fast.

The black boxes below are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. On the real machine at the end of the module, the mission uses these same connectors for real, and you chain them yourself.

The shell lets you wire commands together on one line with tiny connectors called operators. The simplest of them all is the semicolon, ;. It means: run the command on the left, wait for it to finish, then run the command on the right. Nothing more, nothing less.

The semicolon is the oldest connector in the family. It has been separating commands since the very first Unix shell in the early 1970s, and it has meant exactly the same thing ever since.

This whole module is about connectors, and each one gets its own lesson. Coming up are &&, which runs the next command only if the last one worked, and ||, which runs the next only if the last one failed. The semicolon is the one that does not judge. It runs everything, in order, no matter what happens along the way.

Time to run the mystery line. You will chain three echo commands with semicolons. Remember, echo simply prints its words, which makes the running order easy to see.

Before you run it, decide: will the three words land together on one line, or will each appear on its own line?

echo one; echo two; echo three

prompt: student@linuxcamp:~$ answer: echo one; echo two; echo three output: one two three hint: Three echo commands joined by semicolons: echo one; echo two; echo three

Three separate lines. The shell split your line at each semicolon and ran three commands, left to right: first echo one, then echo two, then echo three. Each was its own command with its own output, so each printed on its own line. One press of Enter, three commands. That is the semicolon.

What happens when a command in the middle of a chain fails? Does the whole line stop?

To test that, you need a command that is guaranteed to fail. The shell ships one: false does nothing at all except fail. Its partner true does nothing except succeed. Both get a proper lesson later in this module, in the exit codes lesson. Here, false is just a convenient way to put a certain failure at the front of a chain.

Before you run this, commit to a prediction: after false fails, will the echo behind the semicolon still run, or does the failure kill the rest of the line?

false; echo still-runs

prompt: student@linuxcamp:~$ answer: false; echo still-runs output: still-runs hint: The word false, a semicolon, then echo still-runs: false; echo still-runs

still-runs printed. false failed, and the shell moved straight on to echo still-runs as if nothing had happened. That is the semicolon's whole personality: pure sequencing, blind to success or failure.

Often that is exactly what you want. But sometimes a failure should stop the chain: no point running a program if the build before it broke. For that you need a connector that checks how the last command went. That connector is &&, and it has its own lesson next.

Pause and notice what just happened. Two steps ago, one command per line was all you knew. You have now written one-line sequences and even predicted how they behave around a failure. That is the core skill of this whole module: reading a line of connectors and knowing what runs, in what order.

One more behavior to see, and it trips up most beginners at least once.

Some commands print nothing when they succeed. Remember from the mkdir lesson: mkdir demo creates a directory named demo and, when it works, prints nothing. And remember from the ls lesson: ls demo lists what is inside demo, and a brand-new directory is empty, so there is nothing to list.

Chain them with an echo at the end. Three commands will run. Before you press Enter, decide exactly how many lines of output you expect to see.

mkdir demo; ls demo; echo done

prompt: student@linuxcamp:~$ answer: mkdir demo; ls demo; echo done output: done hint: Three commands, two semicolons: mkdir demo; ls demo; echo done

One line: done. But all three commands ran. mkdir demo succeeded silently. ls demo ran too, and listed the new directory faithfully: it is empty, so the listing was empty. Only echo had anything to say.

Burn this into memory, because it applies to every chain you will ever write: no output does not mean not run. In a chain of quiet commands, silence is usually the sound of success.

Three challenges. This time no command is shown, only the goal. Everything you need is the semicolon plus commands you have already used in this lesson.

Challenge 1. Print one, then two, then three, each on its own line, with a single press of Enter.

prompt: student@linuxcamp:~$ answer: echo one; echo two; echo three output: one two three hint: Three echo commands. One connector joins them into a single line.

Challenge 2. In one line: create a directory named demo, list what is inside it, then print done.

prompt: student@linuxcamp:~$ answer: mkdir demo; ls demo; echo done output: done hint: Three commands, two semicolons. Remember which of the three actually prints anything.

Challenge 3. Put a guaranteed failure at the front of a chain, then prove the shell kept going by printing still-runs.

prompt: student@linuxcamp:~$ answer: false; echo still-runs output: still-runs hint: You met a command whose only job is to fail. Follow it with an echo.

All three from memory, no command shown. You now own the semicolon.

You earned this cheat sheet. Every row is something you just ran yourself:

The one idea underneath it all: the semicolon is pure sequencing. It never looks at how the last command went. When you need a connector that does look, the next two lessons hand you && for success and || for failure.

When a chained line surprises you, read it semicolon by semicolon, left to right, and say each command out loud. The shell runs it exactly that way: one at a time, waiting for each to finish before starting the next.

You typed every form that matters: a plain three-command sequence, a chain that shrugged off a failure, and a chain of silent commands where only the last one spoke. Then you rebuilt all three from nothing but the goal.

Next in this module: the and-operator &&, the or-operator ||, grouping with ( ) and { }, and the exit codes that drive them all. The module ends with one real Linux machine, the chaining mission lab. There you run these moves on a live workspace, and it only tests the operators these lessons teach, nothing new. The mission shows goals, not commands. You read each objective, recall the connector, and type it, exactly the recall you just practiced here.

Practice The semicolon: run commands in sequence in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.