yes

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

Control the one command built to never stop. yes repeats a line forever, so you learn to bound it with head, swap its default y for your own word, stop a runaway with Ctrl+C, and read the harmless Broken pipe message. The classic yes rm -i auto-confirm use is shown, never run.

Every command you have met so far does its job and hands the prompt back to you. ls lists, then stops. date prints the time, then stops. This lesson is about the one command built to do the opposite. It prints a line, then prints it again, then again, and never stops on its own.

It sounds useless. It is one of the most quietly useful tools on the system. Its name is yes, and by the end of this lesson you will know exactly how to switch it on, how to switch it off, and the one job it was made for.

The black boxes below are a practice terminal: a safe sandbox that only checks the one command each step teaches, so nothing here can run away from you. Because a bare yes truly never stops, every box in this lesson bounds it on purpose, so what you type always ends cleanly and prints the same thing every time.

yes prints a line of text over and over, as fast as the machine can, until something stops it. With no argument, the line it repeats is the single letter y. That is the whole behaviour: one line, forever.

The name is a clue to its purpose. Many older programs pause and ask you to confirm before they do something, printing a question and waiting for you to type y for yes. yes exists to answer that question automatically, again and again, so a program that asks a hundred times gets a hundred answers without you sitting there tapping the key.

yes has shipped with Unix since the 1970s and lives today in GNU coreutils, the same toolbox that gives you ls, cat, and wc. It has no real options to learn. The whole skill is controlling something that, by design, will not stop itself.

Here is the golden rule, learned first so you never get bitten: never run a bare yes unless you have a way to stop it. The safe, everyday way to SEE what yes produces is to bound it, to cut it off after a fixed number of lines. The tool that does the cutting is head, which you met earlier: head -3 keeps only the first 3 lines and discards the rest.

The vertical bar | between them is a pipe. It takes what yes prints and feeds it straight into head instead of onto your screen. So yes | head -3 means: let yes start repeating, but hand its output to head, which keeps the first 3 lines and then stops the whole thing. Run it:

yes | head -3

prompt: student@linuxcamp:~$ answer: yes | head -3 output: y y y hint: Type yes, a space, the pipe bar, a space, then head -3: yes | head -3

Three lines, each a single y, and then the prompt came back. That is yes doing its one trick, letter y on repeat, with head -3 acting as the off switch after three lines. Without head, those y letters would have kept coming forever. This pattern, yes | head -N, is how you safely look at yes any time you want to.

yes does not have to say y. Give it a word, or several words, and that becomes the line it repeats instead. The text you hand it is called an argument, and it is the only thing yes accepts. There are no flags to memorise here.

Tell yes to repeat the word hello, and bound it to two lines so it ends cleanly:

yes hello | head -2

prompt: student@linuxcamp:~$ answer: yes hello | head -2 output: hello hello hint: Put your word right after yes, then bound it: yes hello | head -2

Two lines, each reading hello. The moment you gave yes an argument, it swapped its default y for your text and repeated that instead. Everything else is identical: it would have printed hello forever if head -2 had not stopped it after the second line. Whatever you type after yes becomes the line on repeat.

Now the thing you were protected from. If you run yes completely on its own, with no pipe and no head, it does exactly what it promises: it fills your screen with y, line after line, faster than you can read, and it will not stop by itself. Nothing is broken. The command is simply doing its job with no off switch attached.

The off switch you attach by hand is Ctrl+C: hold the Control key and press C. That keypress sends a stop signal to the running command and returns you to the prompt. Ctrl+C is the universal way to stop any command that is still running, and it is exactly what rescues you here.

This is the one place in the lesson where what you would see depends on your machine, so read it for shape, not for an exact count:

y
y
y
y
... thousands more, scrolling until you press Ctrl+C

How many y lines scroll past before your Ctrl+C lands depends on your machine's speed and your reaction time. The count is different every time, so no number is shown here on purpose. The lesson is not the count, it is the reflex: a runaway command is stopped with Ctrl+C. That is why every practice box in this lesson pipes yes through head, so you never need the rescue in the first place.

Now the payoff, the real job behind this odd little tool. Some commands stop and ask you to confirm each action. A classic example is deleting files in interactive mode, where the system prints a question like remove file? and waits for you to type y and press Enter, once for every file. Answer a hundred questions by hand and you will make a mistake.

Piping yes into such a command answers every one of those prompts for you. The shape of it looks like this, and you should recognise it, not run it:

yes | rm -i somefile

yes feeds an endless stream of y into rm -i, so each remove file? question is answered y automatically and the removal proceeds without you touching the keyboard.

Do not run that rm line here or anywhere as a test. It really deletes files, and yes makes it delete every one it is offered without stopping to let you reconsider. It is shown so you understand WHY yes exists, an auto-confirmer for prompts. Only ever point it at a command when you are certain you want every prompt answered yes.

There is one message yes sometimes prints that looks like an error but is not. When you bound yes with head, head takes the lines it wants and then closes the pipe and exits. But yes is still trying to write more y into a pipe that just closed. The system tells yes the reader is gone, and yes may print this line before it quits:

yes: standard output: Broken pipe

Read that plainly. It means: yes tried to write another line, but the thing reading it (head) had already finished and walked away. That is the completely normal end of a yes | head pipeline, not a failure. Your y or hello lines still printed correctly above it. Most of the time you will not even see this message, and when you do, it is safe to ignore.

The thing to check first, if you ever see Broken pipe somewhere it surprises you, is simply whether the command AFTER the pipe finished early on purpose. With head, it always does, so Broken pipe from yes | head is expected and harmless. It is the pipeline ending, not breaking.

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

You want yes to repeat the word ok, but only three lines of it, and you want the command to end on its own so you never have to reach for Ctrl+C. Combine what you learned: give yes your word, and bound it with head to exactly three lines.

prompt: student@linuxcamp:~$ answer: yes ok | head -3 output: ok ok ok hint: Word after yes, then pipe into head with a count of three. Think yes, then ok, then | head -3.

Three lines of ok, and the prompt returned by itself. You gave yes an argument so it repeated your word, and you bounded it with head -3 so it stopped cleanly after three lines with no rescue needed. That is the whole discipline of yes in one command: choose what it repeats, and always attach the off switch before you run it. You built that from memory, which is exactly the recall the real machine will ask of you.

You earned this cheat sheet. Every row is a form of yes you just ran, or the one rescue you now know:

And the two reflexes that matter more than any flag: bound yes with head so it ends on its own, and if a command ever runs away, stop it with Ctrl+C. yes: standard output: Broken pipe is the normal, harmless end of a yes | head pipeline, not an error.

yes has no flags worth learning, which makes it one of the few commands you fully understand in a single lesson. The skill was never the options. It was controlling a tool that, by design, will not stop itself.

The practice terminal has shown you the shape of yes. You can repeat the default y, repeat a word of your own, bound either one with head so it ends cleanly, stop a runaway with Ctrl+C, and read a Broken pipe message for the harmless thing it is. Every one of those you typed yourself.

The Time module ends with one real Linux machine, the Time mission, and that is where you run these commands for real. A VM boots just for you, with its own live terminal. It hands you objectives that use what you practiced across this module: measuring how long work takes, watching output refresh, pausing on purpose, repeating a line, and counting through a range. 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 Time lessons, then go control a real terminal for yourself.

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