& Background Operator

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

Stop letting long jobs freeze your terminal. Append & to run a command in the background: the shell prints its job number and PID and hands your prompt straight back. Chain several with one ampersand each, redirect a chatty job to a log, and read the Done and Stopped (tty input) lines the shell prints on its own. Your job number is small and yours alone; the PID varies every run.

You start a command that takes a while. A long copy, a backup, a download. You press Enter and then you just sit there. The prompt is gone. The terminal is frozen on that one job, and you cannot type anything else until it finishes. You are locked out of your own shell.

That waiting is a choice, and you can unmake it. There is a single character you add to the end of a command that tells the shell: start this, but do not make me wait. Give me my prompt back right now and let the job run behind the scenes. That character is the ampersand, &, and it is the whole lesson.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches, so you cannot break anything. When you send a job to the background, the shell answers with two numbers: a small job number in brackets and a longer PID. The PID is handed out fresh by the system every single time, so the exact digits you see here are just one real capture. Yours will read differently, and that is expected.

Normally, when you run a command, it runs in the foreground: it takes over the terminal, and the shell waits for it to finish before giving you the prompt back. That is why a long job locks you out.

Put an & at the very end of the command and everything changes. The shell starts the command in the background, which means it runs without holding the terminal. The shell does not wait. It prints two numbers to tell you the job launched, then hands your prompt straight back so you can keep working. The job runs behind the scenes.

Think of it like putting a pot on the stove to simmer. Foreground is standing over the pot until it is done, unable to do anything else. Background is setting a timer, walking away, and getting on with the rest of dinner while it cooks.

The cleanest way to feel this is sleep, a command that does nothing but wait a set number of seconds and then exit. Run bare, sleep 30 would freeze your terminal for a full 30 seconds. Add & and it goes to the background instead, and your prompt comes back at once.

Before you run it, commit to a picture. You are about to see the shell print a line with two numbers, then return your prompt immediately, with the sleep still counting down out of sight.

sleep 30 &

prompt: student@linuxcamp:~$ answer: sleep 30 & output: [1] 12345 hint: Type the command, a space, then a single ampersand at the very end: sleep 30 &

That line is this machine's, captured at one moment. The [1] will be the same for you, because it is the first background job in a fresh shell, but the 12345 is a PID the system picked this once. Your PID will be a different number. What is worth reading is the SHAPE of the line, explained next.

Read the line left to right. The [1] is the job number: a small counter the shell keeps just for you, starting at one and counting up as you launch more background jobs. It is how you will refer to this job later. The 12345 is the PID, the process ID, a number the whole system uses to name this exact running process. Job number for you, PID for the system. And notice what came after: your prompt, right away. The sleep is still running, but the shell did not wait for it.

The job number is a counter, so the next background job you launch gets the next number. Send a second sleeper off, a longer one this time, while the first is still running.

Before you run it, decide what the bracket number will be. The first job took [1]. So this one should come back as what?

sleep 60 &

prompt: student@linuxcamp:~$ answer: sleep 60 & output: [2] 12346 hint: Same shape as before, another sleep with an ampersand: sleep 60 &

The [2] is the payoff, and it will be the same for you: it is the second background job in this shell, so the counter climbed from one to two. The PID 12346 is again just this run's number and yours will differ. Two jobs are now running behind your prompt at the same time, one counting down from 30, one from 60.

A background job does not vanish quietly. When it finishes, the shell tells you, but politely: it waits until you press Enter and prints a completion line just before your next prompt. That way it never interrupts you mid-keystroke.

You cannot type this line yourself, because the shell prints it on its own when the job ends. So read it as a frame the machine hands you. After the 30-second sleeper from before finishes, the next time you press Enter you will see something like this appear above your prompt:

[1]+  Done                    sleep 30

That line is a representative frame, not something you type. Read the parts: [1] is the job number that just finished, the + marks it as the most recent job the shell was tracking, Done means it exited cleanly, and sleep 30 is a reminder of which command it was. Your PID never appears on this line, so nothing here will differ for you except which command name it shows.

Because & both backgrounds a command AND acts as a separator, you can chain several jobs on one line. Put an & after each command and the shell fires them all off in order, printing a launch line for each.

Send two sleepers away with a single line:

sleep 30 & sleep 60 &

prompt: student@linuxcamp:~$ answer: sleep 30 & sleep 60 & output: [1] 12345 [2] 12346 hint: Put an ampersand after each command so both go to the background: sleep 30 & sleep 60 &

Two launch lines, one per job, because each & sent its command to the background. The [1] and [2] job numbers will match for you in a fresh shell, but both PIDs are this run's and yours will differ. The trailing & on the second command is what backgrounds it too. Drop that last one and the second sleep would run in the foreground and hold your terminal.

Backgrounding does not gag a job. If a command prints while it runs in the background, that output still lands in your terminal, and it can splash across whatever you are typing. Imagine starting a noisy job and then trying to type a command while its messages scroll over your line. Messy.

The fix is to send its output somewhere else. You send a job's normal output to a file with >, and its error output with 2>&1, both from earlier lessons. So the clean way to launch a chatty job in the background is to redirect it to a log file first, then background the whole thing:

sleep 5 > out.log 2>&1 &

prompt: student@linuxcamp:~$ answer: sleep 5 > out.log 2>&1 & output: [1] 12345 hint: Redirect output to a file, then put the ampersand last: sleep 5 > out.log 2>&1 &

The launch line is the same familiar shape, [1] and a PID, so your PID will differ. What changed is upstream: the > out.log 2>&1 sent this job's normal and error output into a file called out.log instead of onto your screen, and the final & backgrounded the whole thing. Now the job can print all it wants without ever touching what you type.

There is a mirror-image problem. A job in the background can print, but it cannot READ from your keyboard. If a background job tries to ask you for input, the system cannot let it steal your keyboard out from under the shell, so it freezes the job instead and tells you.

You will not type this line either. The shell prints it when a background job gets stuck waiting for input it can never receive. Recognise it on sight:

[1]+  Stopped (tty input)

Another representative frame. Stopped (tty input) means the job did not crash, it was paused because it tried to read from the terminal (tty is the terminal) and a background job is not allowed to. The [1]+ names which job. The cure lives in the next lessons: you pull the job back to the foreground so it can read, using tools called fg and jobs.

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

You want to start a job that waits 45 seconds, but you refuse to let it freeze your terminal. Send it to the background so your prompt comes back the instant you press Enter, and let it count down out of sight.

prompt: student@linuxcamp:~$ answer: sleep 45 & output: [1] 12345 hint: Take the waiting command and add the one character that backgrounds it, at the very end. Think sleep, the number of seconds, then the ampersand.

The move is sleep 45 &. The sleep 45 is the job, and the trailing & is the whole trick: it hands the job to the background and returns your prompt at once. The shell answered with [1] and a PID, and your PID will differ from the one shown, but the [1] is right because it is the first background job in the shell. You recalled the operator from its job alone, which is exactly the recall the real machine will ask of you.

You earned this cheat sheet. Every row is a form of & you just ran or a frame you can now read:

The [n] in every one of those is the job number, small and yours alone. The other number on the launch line is the PID, which the system assigns fresh each time, so it changes on every run. Job number for you, PID for the system.

The & is the doorway into a whole family of controls. Once a job is in the background, jobs lists them, fg pulls one back to the foreground, and bg resumes a paused one in the background. Those are the next lessons. This one gave you the door: & is how a job gets there in the first place.

The practice terminal has shown you the shape of &: the launch line with its job number and PID, the counter climbing as you launch more, chaining several on one line, redirecting a chatty job to a log, and the two frames the shell prints on its own, Done and Stopped (tty input). Every command you typed yourself, and the last one you recalled from its job alone.

The Job Control module ends with one real Linux machine, the Job Control capstone mission, and that is where you send real jobs to the background and manage them live. A VM boots just for you, with its own shell and its own PIDs. It hands you objectives that use exactly what you practiced across this module: backgrounding jobs, listing them, pausing them, and pulling them back to the foreground. 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 Job Control lessons, then go run real jobs in the background for yourself.

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