true

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

Meet true, the command that does nothing and always succeeds. It prints nothing and exits 0, so you reveal that hidden result with echo $?. Its twin false always exits 1, while true drives infinite loops, the colon is its short spelling, and it ignores every argument you hand it. The building block of shell logic.

Here is a command that seems broken. Type it, press Enter, and nothing happens. No output. No error. Just a fresh prompt, waiting.

It is not broken. It did exactly what it promises: nothing. The command is called true, and doing nothing is its entire job. That sounds useless. It is not. true is one of the most-used commands in shell scripting, and this lesson shows why a command with no output earns its own place.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches, so you cannot break anything. Unlike most commands you have met, true prints the same thing on every machine, which is nothing at all. So its outputs here are not a sample; they are exactly what you will see everywhere.

true does two things, and only two. It produces no output, and it finishes with a success result. That is the whole command.

To understand why that matters, you need one idea from earlier: the exit code. Every command, when it finishes, hands back a single number to the shell. 0 means success, everything went fine. Any other number means failure. You met this in the $? lesson, where $? is the variable that holds the exit code of the last command that ran.

true is the command whose exit code is always 0. Think of it as a green light that never turns red. It moves nothing and says nothing, but it always signals go.

true has been part of Unix since the 1970s. The oldest versions were not even a program with code inside: the file was empty. An empty file, run as a command, does nothing and succeeds, which was exactly the point. The behavior was so simple it needed no instructions at all.

Run true on its own and you see nothing, so you have no way to know it worked. The result is real, but it is invisible. To make it visible, you ask the shell for it.

The trick is to run two commands on one line, separated by a semicolon. First true runs, then echo $? prints the exit code true just handed back. The ; simply means do this, then do that.

Before you run it, decide what you expect the number to be. true always succeeds, and success is 0. Now confirm it:

true; echo $?

prompt: student@linuxcamp:~$ answer: true; echo $? output: 0 hint: Type true, a semicolon, a space, then echo $?: true; echo $?

The 0 is the whole point. true itself printed nothing; the 0 you see came from echo $?, which asked the shell what exit code the last command left behind. Because that last command was true, the answer is 0, success. You will get 0 here every single time. There is no input, no argument, no phase of the moon that can make true return anything else. That guarantee is exactly what makes it useful.

true has a twin that does the opposite. false also prints nothing, but it always exits with 1, the plainest signal for failure. Seeing the two side by side is the fastest way to feel what an exit code really is.

Run false the same way, with echo $? to reveal its hidden result:

false; echo $?

prompt: student@linuxcamp:~$ answer: false; echo $? output: 1 hint: Same shape as before, but with false instead of true: false; echo $?

One command gives 0, the other gives 1, and neither prints a word of its own. That is the pure form of an exit code: a yes-or-no answer with no chatter attached. true is the reliable yes, false is the reliable no. Real commands set their exit codes too. A copy that works exits 0; a copy that fails exits non-zero. But true and false are the two you reach for when you want that signal on demand, with nothing else in the way.

Now the payoff. The most common place you will see true is at the top of a loop. A while loop keeps running as long as its condition succeeds. Give it true as the condition and the condition never fails, so the loop runs forever. That is called an infinite loop, and it is how monitors, retry logic, and menus stay alive: keep going until something stops you.

Running a truly endless loop in a practice box is a bad idea, so this one has a built-in escape. break means leave the loop now. This loop prints one line, then breaks, so it stops on its own. Notice the do and done: every while loop wraps its body between those two words.

while true; do echo looping; break; done

prompt: student@linuxcamp:~$ answer: while true; do echo looping; break; done output: looping hint: Wrap the body in do and done: while true; do echo looping; break; done

It printed looping once and stopped, because break cut the loop after the first pass. Take the break out and this same loop would run forever, printing looping as fast as it can, until you press Ctrl+C to kill it. That is not a bug; it is the design. while true is how you say keep doing this until I say stop, and true is the piece that makes the loop never quit on its own.

There is a second way to write true, and you will meet it in older scripts. The colon, :, is a shell builtin that does the exact same thing: it takes no action and exits 0. It is true with fewer letters, and it has been in the shell since the 1970s.

Prove they behave identically. Run a colon on its own and reveal its exit code the same way you did for true:

:; echo $?

prompt: student@linuxcamp:~$ answer: :; echo $? output: 0 hint: Type a single colon, a semicolon, then echo $?: :; echo $?

Same 0, same silence. The colon is a synonym for true: anywhere true fits, : fits too, including as a loop condition, while :; do ...; done. Most engineers write true today because it reads like a word, but you will run into : in scripts written long ago, and now you know it is not a typo. It is just the old, short spelling of do nothing and succeed.

One last habit of true surprises people. Most commands care about their arguments: give ls a folder that does not exist and it complains. true does not care about anything. Hand it a word, a filename, gibberish, and it shrugs and exits 0 anyway. It reads nothing, checks nothing, and always succeeds.

Test it. Feed true an argument it has no reason to accept, then check the exit code:

true nonsense; echo $?

prompt: student@linuxcamp:~$ answer: true nonsense; echo $? output: 0 hint: Put any word after true, then reveal the code: true nonsense; echo $?

Still 0. The word nonsense was completely ignored. This is the closest thing true has to an error, and it is not really an error at all: true cannot fail, so nothing you pass it changes the outcome. Compare that to a normal command, where a bad argument means a failure and a non-zero exit code. true has one answer to every question, and the answer is always success.

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

You have seen true hand back 0 again and again. Now show its opposite for yourself, from memory. Run the command that always fails, and in the same line reveal the exit code it leaves behind, so the failure signal 1 prints on screen.

prompt: student@linuxcamp:~$ answer: false; echo $? output: 1 hint: Use the twin of true, then the same reveal trick you have used all lesson: the command, a semicolon, then echo $?.

That 1 is the failure signal, printed on demand. You recalled the failing command, false, and paired it with echo $? to expose the exit code, exactly the move you used to reveal true. Hold both in your head: true for 0, false for 1. That pair is the mental model the rest of shell scripting is built on. Commands succeed or fail, and the exit code is how they tell you which.

true cannot really fail, so the errors you meet near it come from the shell around it, not from true itself. Here are the two you are most likely to trip over, with what each one means and what to check first:

The message bash: syntax error near unexpected token 'done' means your while loop is missing its do. Check that the shape reads while true; do ...; done. Every while needs a do, and every do needs a matching done.

The message command not found after you meant to type true almost always means a typo, ture, treu, or a stray space. Check the spelling. true is five letters with no capitals and no arguments.

You may see mention of a file at /usr/bin/true, a real program on disk that also does nothing and exits 0. When you type true in bash, the shell uses its own faster built-in version, not that file. Both behave the same, so for everyday work you never have to think about which one ran.

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

The one idea under all of it: true is the reliable success signal, false is the reliable failure signal, and echo $? is how you read the signal that a command leaves behind but does not print.

Whenever a script needs a guaranteed yes (a loop that should not quit, a branch that must run, a placeholder that must succeed), true is the piece that supplies it. When you want a guaranteed no for testing, reach for false. They are a matched pair.

The practice terminal has shown you the whole of true. It prints nothing and always exits 0. echo $? reveals that hidden code. false is its 1-returning twin, while true loops forever, and the colon : is its shorter spelling. Every one of those you typed yourself.

The Special module ends with one real Linux machine, the module capstone mission, and that is where you put these pieces to work for real. A VM boots just for you, with a 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 always succeed on a real machine.

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