false

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

Meet false, the mirror image of true: it prints nothing and always exits 1. See the failure with echo $?, trigger the fallback it guarantees, watch it ignore its arguments, and switch off a loop with while false. false is deterministic, so every output here is exact.

You just met true, the command whose entire job is to succeed and do nothing else. This lesson is its mirror image. false is a command whose entire job is to FAIL, and do nothing else.

That sounds even more useless than true. Why would anyone want a command that is guaranteed to fail? The answer is the same reason true is useful. In shell scripting you often need a known, guaranteed outcome to build on, and sometimes the outcome you need is a failure. false is the reliable failure you reach for.

The black boxes in this lesson are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. Unlike most lessons, the outputs here are exact. false behaves identically on every Linux machine, so what you see in the sandbox is exactly what you will see on the real machine.

Every command in Linux finishes by handing back a small number called an exit code. An exit code of 0 means success. Any other number means failure. You met exit codes and the $? variable that holds the last one in an earlier lesson.

false does exactly two things. It produces no output at all, and it exits with the code 1. That code 1 is the whole point. It is a small, honest way of saying "something went wrong," on demand, whenever a script needs it.

Here is the part that surprises beginners. When you run false, you see nothing happen. No message, no error, no text. The command ran, failed quietly, and gave your prompt straight back. Run it now and watch nothing appear:

false

prompt: student@linuxcamp:~$ answer: false output: hint: Just type the word false and press Enter. It prints nothing on purpose.

Empty. No output is not a mistake, it IS the behaviour. false never prints anything. The only visible sign it did anything is that your prompt came back. To actually SEE that it failed, you have to ask for its exit code, which is exactly what the next step does.

Since false prints nothing, you need a way to see the 1 it hands back. The special variable $? holds the exit code of the last command that ran. Print it with echo $? right after false and the hidden 1 comes into view.

Run the two commands together, separated by a semicolon so they run one after the other on one line:

false; echo $?

prompt: student@linuxcamp:~$ answer: false; echo $? output: 1 hint: Run false, then a semicolon, then echo $? to print the exit code: false; echo $?

There it is: 1. That single digit is everything false exists to produce. Compare it in your head with true, which prints nothing either but leaves $? at 0. Same silence, opposite meaning. true is silent success, false is silent failure, and echo $? is how you tell them apart.

The || operator, said "or," runs the command on its right ONLY if the command on its left failed. It is the shell's way of saying "try this, and if it goes wrong, do that instead." You met it in the chaining lessons.

Because false always fails, it always triggers the || fallback. That makes it the perfect way to prove your recovery path works. Wire a fallback message behind false and watch the message fire:

false || echo recovered

prompt: student@linuxcamp:~$ answer: false || echo recovered output: recovered hint: Type false, then two pipe characters, then echo recovered: false || echo recovered

The word recovered printed. false failed, so || reached over to the right-hand side and ran echo recovered. This is the everyday use of false. When you are building a script and want to be certain the failure branch actually runs, you drop in false and watch the fallback fire, every time, no guessing.

You might reasonably guess that handing false some arguments changes what it does. It does not. false ignores every argument and every option you throw at it. It still prints nothing, and it still exits 1. Nothing you type after it can make it succeed.

Prove it. Give false a nonsense argument and check the code anyway:

false foo; echo $?

prompt: student@linuxcamp:~$ answer: false foo; echo $? output: 1 hint: Type false, a space, the word foo, a semicolon, then echo $?: false foo; echo $?

Notice what did NOT happen. false foo did not complain that foo is not a real file or option. It did not error at all. It swallowed the argument and exited 1 just like bare false. This is different from most commands, which would object to an argument they do not understand. false has no arguments to understand, so it never objects.

A while loop keeps running its body for as long as its condition succeeds. Feed it true and the loop runs forever. Feed it false and the loop body never runs even once, because the condition fails on the very first check.

This is false used as a deliberate off switch. The loop is written, but it is guaranteed to skip its body. Run one and see that nothing inside it prints:

while false; do echo inside; done; echo done

prompt: student@linuxcamp:~$ answer: while false; do echo inside; done; echo done output: done hint: while false; do echo inside; done; echo done -- only the final echo runs.

Only done printed. The word inside never appeared because the loop condition, false, failed immediately, so bash skipped the body entirely and moved on to the final echo done. Swapping false for true there would flip it into a loop that runs forever. false is how you write a loop that is switched off by design.

Scaffolding off. No command is printed this time. You have every piece you need.

You are testing a script's recovery path. You want a command that is guaranteed to FAIL, wired so that when it fails, the word recovered prints. Use the command from this lesson that always fails, and the operator that runs a fallback only when the left side fails.

prompt: student@linuxcamp:~$ answer: false || echo recovered output: recovered hint: Think of the always-fail command, then the two-character "or" operator, then echo recovered.

That is the move a working engineer types to test a failure path. false guaranteed the left side failed, so || ran echo recovered and the fallback proved itself. You recalled both the command and the operator from memory, with nothing shown, which is exactly the recall the real machine will ask of you.

You earned this cheat sheet. Every row is a form of false you just ran:

The one number to remember is 1, the exit code false always hands back. When you want a guaranteed failure to test a fallback, an off switch for a loop, or a placeholder that fails on purpose, false is the command to type.

false and true are a matched pair, and you now know both. true is silent success, exit code 0, the && chain keeps going. false is silent failure, exit code 1, the || fallback fires. Whenever a script needs a known outcome to build on, one of these two gives it to you.

The practice terminal has shown you the whole of false. You have the silent run, the 1 that echo $? reveals, the || fallback it triggers, the arguments it ignores, and the loop it switches off. Every one of those you typed yourself.

The Special module ends with one real Linux machine, the Special capstone mission, and that is where you run false and its companions for real. A VM boots just for you, with its own live shell. It hands you objectives that use exactly what you practiced across this module. One difference from here: the mission shows no commands. You read the objective, you recall the command, you type it. That recall is what makes it stick.

Finish the other Special lessons, then go make a shell fail on purpose for real.

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