Linux and Shell Fundamentals Interview Questions

Everything -- including other storage devices -- is mounted somewhere under one single root directory (`/`), rather than appearing as separate drive letters (`C:`, `D:`) -- there's exactly one filesystem tree to navigate, with mount points integrating additional storage seamlessly into that tree.

`>` redirects output to a file, OVERWRITING its existing contents entirely; `>>` redirects output to a file, APPENDING to its existing contents -- using `>` when you meant `>>` is a common way to accidentally destroy previously-logged data.

Common mistake: Using > instead of >> when appending to a log file, silently overwriting all previously-recorded content.

stdout (file descriptor 1) is a program's normal output; stderr (file descriptor 2) is specifically for error/diagnostic messages -- keeping them separate lets you redirect normal output to a file while still seeing errors on the terminal, or vice versa, rather than mixing everything into one stream.

It connects the first command's stdout directly to the second command's stdin, letting you chain simple, focused commands together into a more complex data-processing pipeline -- e.g. `cat access.log | grep "ERROR" | wc -l` counts error lines without any intermediate temp files.

cat access.log | grep "ERROR" | wc -l

An absolute path always starts from the root (`/home/user/file.txt`) and unambiguously identifies a location regardless of your current directory; a relative path (`./file.txt` or `../other/file.txt`) is interpreted relative to the shell's current working directory, so the same relative path can point to different actual locations depending on where you run it from.

Globbing expands a wildcard pattern into a list of matching FILENAMES before the command even runs (e.g. `rm *.txt` becomes `rm file1.txt file2.txt`) -- it's a much simpler pattern language than full regular expressions, matched against actual filesystem entries, not arbitrary text.

Without quotes, the shell performs word-splitting on the expanded value -- a variable holding `"my file.txt"` unquoted expands into two separate arguments (`my` and `file.txt`), which can cause a command to operate on the wrong thing entirely or fail unexpectedly.

Common mistake: Using an unquoted variable expansion (e.g. rm $filename instead of rm "$filename"), causing word-splitting to break on filenames containing spaces.

Plain `cp` fails (or refuses) on a directory by default; `-r` (recursive) tells `cp` to copy the directory and all of its contents, including nested subdirectories -- the recursive flag is required whenever the source is a directory, not just a single file.

A numeric status returned when a command finishes, indicating success or the type of failure -- `0` conventionally means success; any non-zero value indicates some kind of failure, with the specific number sometimes carrying additional meaning depending on the command.

Immediately check the special variable `$?`, which holds the exit status of the last executed command -- it must be checked right away, since running any OTHER command afterward (even something trivial) overwrites `$?` with that new command's exit code instead.

ls /some/path
echo $?  # 0 if the directory exists, non-zero otherwise

`grep` searches text for lines matching a pattern and prints the matching lines; `grep -v` inverts this, printing lines that do NOT match the pattern -- both are essential for filtering large log files or command output down to relevant lines.

grep "ERROR" app.log      # lines containing ERROR
grep -v "DEBUG" app.log   # lines NOT containing DEBUG

`sed` (stream editor) performs text transformations on each line of input -- `s/old/new/g` is a substitute command replacing every (`g` = global) occurrence of 'old' with 'new' on each line, commonly used for find-and-replace in files or piped text.

sed 's/foo/bar/g' input.txt

`awk` is a full pattern-scanning and text-processing language, particularly strong at working with column/field-structured data (e.g. printing just the 3rd whitespace-separated column of every line) -- more powerful for structured data extraction/computation than `grep` (matching) or `sed` (substitution) alone.

awk '{print $3}' data.txt   # print the third column of every line

`sort` orders lines of text; `uniq` removes ADJACENT duplicate lines -- since `uniq` only catches consecutive duplicates, input generally needs to be sorted first so that identical lines end up next to each other before `uniq` can correctly deduplicate them.

sort names.txt | uniq

Common mistake: Piping unsorted input directly into uniq, missing duplicate lines that aren't adjacent to each other.

It prefixes each unique line with a count of how many consecutive times it appeared -- useful for quickly summarizing frequency, e.g. `sort access.log | uniq -c | sort -rn` gives a quick frequency-ranked summary of log lines.

It extracts just the 2nd field (`-f2`) from each line, treating a comma (`-d','`) as the field delimiter -- a quick way to pull out one column from simple delimiter-separated data without a full CSV parser.

`head` shows the first N lines of a file; `tail` shows the last N lines -- `tail -f` ('follow') continues watching the file and streams new lines as they're appended, commonly used to watch a log file in real time as a running application writes to it.

It counts the number of lines in the input -- a quick way to answer 'how many log entries/records/results are there,' e.g. `grep "ERROR" app.log | wc -l` counts how many error lines exist without needing to actually read through them.

Each individual command (`grep`, `sort`, `uniq`, `cut`) is well-tested, well-understood, and reusable -- composing them via pipes lets you build a precise, one-off analysis command quickly, without writing and debugging custom code for something the standard tools already handle well.

Forgetting that `grep` treats certain characters as regex metacharacters by default (`.` matches any character, not just a literal period) -- searching for a literal special character requires escaping it (`\.`) or using `grep -F` for a purely literal (fixed-string) search.

Common mistake: Searching for a literal period with grep without escaping it, causing the pattern to match any character instead of just a period.

`PATH` is a colon-separated list of directories the shell searches, in order, when resolving a bare command name to an actual executable file -- typing `python` causes the shell to search each `PATH` directory in turn until it finds an executable named `python`, running the first match found.

A shell variable exists only within the current shell session; an environment variable (created with `export`) is additionally passed down to any child processes that shell launches -- a variable set without `export` won't be visible to a script or program the shell subsequently runs.

It adds the execute permission to the file -- without it, the operating system refuses to run the file as a program even if its content is valid, correctly-formed script code; the execute bit is a separate, explicit permission from merely being able to read the file's content.

`r` (read) controls viewing a file's content or listing a directory; `w` (write) controls modifying a file or adding/removing entries in a directory; `x` (execute) controls running a file as a program, or entering ('traversing') a directory -- each is set independently for the owner, the owning group, and everyone else.

A unique numeric identifier the OS assigns to each running process -- `ps` (often `ps aux` for a full listing) shows currently running processes along with their PIDs, letting you identify a specific process to inspect or terminate.

`SIGTERM` (the default for `kill`) asks the process to terminate gracefully, giving it a chance to clean up (close files, finish in-flight work) before exiting; `SIGKILL` (`kill -9`) forcibly terminates the process immediately, with no opportunity for cleanup -- `SIGKILL` should generally be a last resort when a process doesn't respond to `SIGTERM`.

Common mistake: Reaching for kill -9 (SIGKILL) by default instead of trying a graceful SIGTERM first, skipping any cleanup the process would otherwise perform.

It runs the command in the background, immediately returning control of the shell prompt rather than waiting for the command to finish -- useful for long-running processes you don't want to block your terminal session on.

Every process (except the very first) is spawned by another (its parent) -- if a parent terminates without properly handling its children, they can become 'orphaned' and are typically re-parented to an init process, or in some cases become 'zombie' processes if their exit status was never collected by the parent.

`sudo` runs the command as a different (typically root) user, which can have a different environment and unrestricted file access -- a script that works without `sudo` might behave differently (or dangerously, given root's broad permissions) when run with it, so `sudo` shouldn't be reached for casually just to bypass a permission error without understanding why it occurred.

File permissions, environment variables (including `PATH`), and even the current working directory can all differ per user -- a script that works for one user might fail for another due to a permission it lacks or a dependency on a `PATH` entry only set up in one user's environment.

It tells the operating system which interpreter should execute the rest of the file when run directly (e.g. `./script.sh`) -- without it, the OS wouldn't know the file is a Bash script rather than, say, a Python script or plain text.

`-e` exits immediately on any command failure; `-u` treats using an undefined variable as an error; `-o pipefail` makes a pipeline fail if ANY command in it fails, not just the last one -- together, these turn Bash's normally-lenient error handling into fail-fast behavior, catching real bugs immediately instead of silently continuing after something already went wrong.

Common mistake: Writing a Bash script without set -euo pipefail, letting a failed command in the middle silently continue as if nothing went wrong.

They hold the arguments passed to the script when it was invoked -- `$1` is the first argument, `$2` the second, and so on, with `$#` giving the total argument count and `$@` representing all arguments as a list.

#!/bin/bash
echo "First argument: $1"

`if [ condition ]; then ... fi` -- a common mistake is omitting the required spaces around the brackets (`[condition]` instead of `[ condition ]`), since `[` is actually a command/program name in this context and needs to be treated as a separate token, not glued to the condition.

Common mistake: Omitting the required spaces inside test brackets ([ condition ] vs [condition]), causing a syntax error since [ is itself a command.

Without an explicit check, the script fails at the point that tool is first called, potentially after already performing some partial, non-idempotent work -- checking dependencies up front (e.g. `command -v jq || { echo "jq required"; exit 1; }`) fails fast with a clear message before any real work has started.

A function is defined and callable within the same shell session/script, sharing that shell's environment directly; a separate script runs as its own new process -- functions are useful for organizing logic within one script, while separate scripts are useful for genuinely independent, separately-invokable tools.

A script invoked with a missing or malformed argument can otherwise proceed to operate on unintended data (e.g. an empty variable expanding to nothing in a `rm` command, accidentally targeting the wrong path) -- explicit validation with a clear error message prevents this class of dangerous, silent misuse.

`$(command)` runs the command and substitutes its stdout output into the surrounding expression/string -- e.g. `today=$(date +%Y-%m-%d)` captures the actual current date dynamically, as opposed to hardcoding a literal date string that would become stale.

Distinct exit codes let a CALLING script or CI pipeline programmatically distinguish different failure types and react appropriately (e.g. retry on a transient network error but not on a validation error) -- a single generic failure code loses that distinction entirely.

An interactive user can notice and react to an unexpected prompt or hang; an unattended script (via cron or CI) has no human watching -- if its error handling is untested and wrong, a failure can go unnoticed for a long time, or worse, cause silent data corruption instead of a clear, logged failure.

It registers a function to run automatically when the script exits, for ANY reason (normal completion, an error, or a signal) -- ensures temporary resources (temp files, background processes) are always cleaned up, even if the script exits early due to an unexpected error partway through.

TMPFILE=$(mktemp)
trap 'rm -f "$TMPFILE"' EXIT

A hardcoded temp file path can collide with another concurrent run of the same script (or another user/process using the same name), causing one run to clobber another's data -- `mktemp` generates a guaranteed-unique filename, avoiding this collision risk entirely.

Common mistake: Hardcoding a temp file path instead of using mktemp, risking a collision if the script runs concurrently or is invoked by multiple users.

There's no human watching the terminal output in real time -- a cron/CI script needs to write meaningful, persistent logs (or send alerts) so failures can be discovered and diagnosed after the fact, rather than relying on someone having happened to be watching the output live.

Cron jobs typically run with a much more minimal environment (a different or empty `PATH`, no interactive shell's loaded profile/aliases, a different working directory) -- a script relying on assumptions from an interactive shell session can fail in cron's stripped-down environment unless it explicitly sets what it needs.

A static-analysis linter for shell scripts that catches common bugs (unquoted variables, incorrect test syntax, portability issues) before the script is ever run -- especially valuable for unattended scripts, where a subtle bug might not surface until it actually causes damage in production, with nobody watching interactively to catch it immediately.

Different systems can have different default shells, different versions/flavors of common utilities (GNU vs. BSD versions of `sed`/`date` have different flag behavior), or missing tools entirely -- a script relying on one specific system's exact tool behavior may behave differently or fail outright elsewhere.

It sends HTTP requests directly from the command line -- commonly used in scripts to call an API, download a file, or perform a health check, without needing a full programming language runtime just to make one HTTP request.

curl -s -o output.json https://api.example.com/data

Command-line arguments are typically visible to other processes/users on the same system (e.g. via `ps aux`) and often end up recorded in shell history files -- environment variables or a dedicated secrets file with restricted permissions are safer ways to pass sensitive values into a script.

Common mistake: Passing a secret directly as a command-line argument, exposing it to other users via ps and to shell history logging.

A wrong current directory or a typo in the path can cause `rm -rf` to delete unintended files with no built-in undo -- a defensive habit is running the equivalent `ls` or `echo` on the same path/glob first to confirm exactly what would be affected, before actually running the destructive command.

Common mistake: Running a recursive delete command directly without first confirming the target path with a non-destructive command like ls.

An unattended script's exit code is often the ONLY signal available to whatever's monitoring it (a CI system deciding pass/fail, a cron-job alerting wrapper) -- a script that always exits 1 regardless of what actually went wrong gives that monitoring system no way to distinguish a transient, retry-worthy failure from a permanent, alert-worthy one.