101-400 · Question #412
Which of the following statements is correct for a command line ending with a & character?
The correct answer is C. The command is run in background of the current shell. See the full explanation below for the reasoning.
Question
Options
- AThe command's output is redirected to /dev/null.
- BThe result of the command defines if the next command will be run.
- CThe command is run in background of the current shell.
- DThe command is run as a direct child of the init process.
How the community answered
(42 responses)- A7% (3)
- B5% (2)
- C74% (31)
- D14% (6)
Community Discussion
6
Toby R.Feb 19, 2026C is the right answer. When you end a command with &, the shell forks it off and keeps running without waiting for it to finish, so it runs in the background of your current shell session. It is still a child of that shell, not of init, so D is wrong. A is just completely wrong, & does nothing to redirect output, you would need something like > /dev/null 2>&1 for that. B describes the && operator, which is a totally different thing.
Tom W.Feb 18, 2026Yep, C, seen guys get burned picking D every single time because they confused backgrounding with nohup.
Devraj B.Jan 29, 2026D trips up a lot of candidates because there is a kernel of truth buried in it, specifically that daemons orphaned from a terminal eventually get reparented to init or PID 1, but a plain ampersand does not do that, it simply moves the job to the background while keeping it a child of your current shell. The answer is C, LPI objective 103.1 weight 4, and your memory hook is this: ampersand equals "and keep going," meaning the shell keeps going and the job keeps going, both alive together.
Tom W.Feb 1, 2026Good hook but finish the thought, because that backgrounded job will still catch a SIGHUP and die when the terminal closes, which is what they used to call the whole reason nohup got invented.
Thiago A.Feb 12, 2026C is the answer. Worth noting that D trips people up because jobs sent to background with & are still children of the current shell, not init, you can confirm that with ps -o pid,ppid,cmd after running sleep 60 & and comparing the PPID to your shell's PID.
Tom W.Feb 12, 2026Good point on the ps check, and worth adding that on systemd boxes the orphan gets reparented to PID 1 which is systemd, not what they used to call init, so do not be surprised when you see that in the PPID column on a modern distro.