Linux interview questions – practice quiz with real questions

By POSIX convention, a command that succeeds returns an exit status of 0. Non-zero values (1–255) indicate failure, with the specific number sometimes carrying meaning.

$? expands to the exit status of the most recently executed foreground command. It is typically checked immediately after a command to decide whether it succeeded (0) or failed (non-zero).

set -e (short for set -o errexit) makes the shell exit immediately if any command fails with a non-zero exit status, unless that command is part of an if or &&/|| test. This helps scripts fail fast instead of continuing after errors.

Bash supports two syntaxes for defining a function: function myfunc { ... } and myfunc() { ... }. The parentheses form is fully valid and widely used, so the statement that function is the only allowed keyword is false.

Every if construct in bash is closed with fi, no matter how many elif or else branches it contains. This mirrors bash's convention of closing blocks with the reversed keyword (e.g., case/esac).

In the long-format output of ls -l, the first character of each permission string encodes the file type: d for directory, - for regular file, l for symbolic link, c for character device, b for block device, and so on. The remaining nine characters represent read/write/execute permissions for owner, group, and others.

grep returns exit code 0 when at least one line matches, 1 when no lines match, and 2 when an error occurs (e.g., file not found or invalid option). Since the file exists but contains no matching lines, grep exits with status 1, so $? is 1.

Bash uses elif (a contraction of 'else if') to chain additional conditional branches. Each elif is followed by a test in square brackets or double parentheses, then then. Using else if as two separate words does not work in bash — that would start a nested if inside the else block and require an extra fi.

Inside for, while, and until loops, break exits the enclosing loop entirely (optionally with a numeric argument to break out of N nested loops), while continue stops the current iteration and re-evaluates the loop condition for the next one. Both are shell builtins and behave the same way regardless of the loop type.

The Bash manual defines the expansion order as: (1) brace expansion, (2) tilde expansion, (3) parameter/variable/command/arithmetic expansion, (4) word splitting, (5) pathname expansion, and (6) quote removal. This fixed sequence explains observable behaviors — for example, a glob pattern produced by parameter expansion is still expanded because parameter expansion (step 3) precedes pathname expansion (step 5), while the results of pathname expansion are never re-split because word splitting (step 4) has already completed.

Bash processes the unquoted $files through three relevant phases. First, parameter expansion replaces $files with its value, the literal string report *.log. Because the expansion is unquoted, word splitting then acts on that result, splitting on the default IFS (space) into report and *.log. Finally, pathname expansion treats *.log as a glob pattern and replaces it with matching filenames in the current directory (error.log and server.log). Quote removal would follow but has no visible effect since no quote characters remain. The echo command ultimately receives three arguments: report, error.log, and server.log.

Bash functions use return to set an exit status, which is an unsigned 8-bit value (0–255). Any argument to return is reduced modulo 256, so return 300 produces 300 - 256 = 44.

When no return is issued, bash uses the exit status of the last command run inside the function as the function's own exit status, just as a script without an explicit exit returns the status of its final command.

By default a pipeline returns the status of its last command (without set -o pipefail, a pipeline's exit status is the exit status of the last command in the pipeline). Without pipefail, intermediate failures in a pipeline are invisible to set -e, so the claim that with set -e but without set -o pipefail, a bash script exits immediately if any command in a pipeline fails, even when the last command succeeds is false. Exit codes of 128+N conventionally mean the process was killed by signal N; SIGINT is signal 2, so 130 = 128+2 (an exit code of 130 (128 + 2) indicates the process was terminated by SIGINT (signal 2)). $? is defined as the exit status of the most recently executed foreground pipeline.

The bash manual lists several exemptions from set -e: commands in an if/elif test (a command whose return value is tested as the condition of an if statement), commands in a &&/|| list except the one after the final &&/|| (a command that is the left operand of && — the left operand of && is not after the final &&), and commands whose status is inverted with ! (a command whose exit status is inverted with !). The last command in a pipeline with pipefail enabled describes the last command in a pipeline with pipefail enabled; when it fails the pipeline's status is non-zero, so set -e does exit — making it incorrect.

Under /proc/<pid>/, the cmdline file holds the process's argv array with each argument separated by a null byte, and the maps file shows each virtual memory mapping the process currently holds — including shared libraries, the heap, the stack, and any file-backed mappings. These are kernel-provided pseudo-files, so they exist for any running process without needing external tools.

Bash first enumerates all elements of the array in index order. The offset (1) is then applied, selecting the starting element at index 1 (i.e., b). Next, the length (2) determines how many elements to take from that point — b and c. Finally, because the [@] form is used, each selected element is emitted as a separate word, so the result is two words: b and c.

The question is explicitly pinned to bash 4.4+, where the behavior is well-defined: when a function's return value is tested by the caller (if/while/until condition, or the left side of ||/&&), bash 4.4+ disables set -e for the entire function body — not just the function-call command. This is a change from bash 4.3 and earlier, where only the function-call command itself was exempt and a failing non-tested command inside the function would still trigger set -e. The behavior also differs across shells: POSIX sh, dash, and ksh do not implement the whole-function toggle. Pinning to bash 4.4+ eliminates the ambiguity and makes the answer deterministic.

Bash exit statuses are 8-bit unsigned integers (0–255). return is functionally identical to exit for this purpose but only exits the function, not the script. Knowing this limit is essential for designing functions that need to signal distinct error categories — a common senior-level scripting pitfall when return codes are used as error enumerations.

This is one of the most insidious bash gotchas. When local (or declare) is combined with an assignment that includes a command substitution, the local builtin's own successful exit status (0) is what $? reports. Under set -e this also means the failure is silently swallowed because the overall command (local var=...) succeeds. Splitting the declaration and assignment is the standard fix and a hallmark of senior-level bash fluency.

Per the bash manual, set -e does not cause exit when the failing command is part of the test following if/elif/while/until (the failing command appears in the condition of an if statement), is any command in a &&/|| list except the one following the final &&/|| (the failing command is the first operand in a cmd1 && cmd2 list — the first operand of && is not the final command), is any command in a pipeline but the last (the failing command is a non-last command in a pipeline without pipefail set), or has its return value inverted with ! (the failing command's exit status is inverted with !). The failing command is the last command in a pipeline without pipefail set is NOT an exception: without pipefail, the pipeline's exit status equals the last command's status, so if the last command fails the pipeline fails and set -e triggers.

Bash is one of the few widely-used languages that uses dynamic scoping rather than lexical scoping for local variables. This is a deep, often surprising behavior that affects how functions interact through shared variable names, and it is a key distinction at the staff level for shell scripting internals.

By default (without pipefail), bash sets $? to the exit status of the last command in a pipeline. In false | true, the last command is true, which exits 0. Because the overall pipeline exit status is 0, set -e sees success and does not trigger shell exit. Enabling set -o pipefail would change this: the pipeline would return the rightmost non-zero exit status (1 from false), and set -e would then cause the shell to exit.

The bash manual states that the ERR trap is not executed if the failed command is part of the test in an if statement (or a while/until condition), part of a &&/|| list except the last command, or if the command's return value is inverted with !. These are the same contexts in which set -e is also suppressed, because the non-zero status is being consumed as a Boolean value rather than treated as an error. Therefore a failing command in an if condition does trigger neither set -e nor the ERR trap.

Three parameter-expansion operators combine here. First, ${s/*:/X}: the pattern *: is a glob where * is greedy, so it matches the longest prefix ending in : — alpha:beta:gamma: — and the single / replaces that one match with X, yielding Xdelta. Second, the nested ${s##*:} removes the longest *: from the front of s, leaving delta. Third, ${s/%delta/X} uses % to anchor the pattern to the end of the string; delta matches there and is replaced with X, yielding alpha:beta:gamma:X. The literal : sits between the two expansions, so the full output is Xdelta : alpha:beta:gamma:X.