A cron entry runs a maintenance script under /bin/sh (dash on this Debian host) and must never generate mail: neither its normal output nor its error messages may reach cron. Which ending to the cron command line discards both streams reliably on that shell?
LPIC-1 Exam 101-500, objective 103. GNU and Unix commands hard
Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.
Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
The options
Correct >/dev/null 2>&1
Correct. Standard output is opened on /dev/null first, then descriptor 2 is made a duplicate of descriptor 1, which by then already points at /dev/null. This form is POSIX and works in every Bourne-compatible shell.
Not correct &>/dev/null
Wrong here. &> is a bash and zsh extension; dash parses the ampersand as the background operator, so the script is put into the background and an empty command is redirected. The error messages still escape.
Not correct 2>&1 >/dev/null
Wrong. Redirections are applied left to right: descriptor 2 is pointed at wherever descriptor 1 currently goes (cron's pipe), and only afterwards is descriptor 1 moved to /dev/null. Errors still generate mail.
Not correct >/dev/null 2>1
Wrong. Without the ampersand, 2>1 is an ordinary output redirection to a file literally named 1, created in the working directory. Errors are diverted, but into a stray file rather than discarded.
Why
n>&m duplicates descriptor n onto whatever descriptor m points at that instant, so the order of redirections on the line decides the result: put the target redirection first and the duplication second. The ampersand distinguishes duplication (2>&1) from a plain file target (2>1). &>file is a convenient bash shorthand for the same effect, but it is not portable to /bin/sh.
Where this comes from
- Cited
- manual page bash(1)
Practise this
Reading one question is not practice. The trainer will draw a short set from objective 103 and space the ones you get wrong.
More questions on this objective
- A user starts a new terminal window in a running graphical desktop session, which launches bash as an interactive shell that is NOT a login shell. Which file in the user's home directory does bash read in that case? machine-checked
- In bash, which history expansion re-runs the entire previous command line? machine-checked
- Which bash command prints the literal five characters $USER instead of the current user name? machine-checked
- You want /opt/bin searched for executables, after all the directories already in PATH, in the current bash session and in every command started from it. Which command does that? machine-checked
- There is a passwd manual page in section 1 (the command) and another in section 5 (the /etc/passwd file format). Which command opens the section 5 page? machine-checked
- Select the TWO true statements about shell variables and the environment in bash. machine-checked