Top 60 Shell Scripting Interview Questions (2026)

A shell script is a text file of shell commands that the interpreter runs in order. It turns a set of manual terminal steps into one repeatable program you can run, schedule, and version.

Teams use them for automation that lives close to the system: backups, log rotation, deployment steps, batch file operations, and glue between other command-line tools. The shell is already on every Linux box, so there's nothing extra to install.

The shebang is the first line, #!/bin/bash, that tells the kernel which interpreter should run the file. Without it, the script runs under whatever shell the caller happens to use, which can change behavior.

It's only honored when you execute the file directly (./script.sh). Running it as bash script.sh ignores the shebang because you've already named the interpreter.

Double quotes allow variable expansion and command substitution while preventing word splitting and globbing. Single quotes are fully literal: nothing inside expands, so $HOME stays the text $HOME.

The practical rule: reach for double quotes around variables so values with spaces stay intact, and use single quotes when you want the text exactly as written.

Assign with name=value and no spaces around the equals sign, then read it with $name or ${name}. Everything is a string by default; there are no separate number or boolean types.

Spaces around = are the classic beginner error: x = 5 tries to run a command called x. Use the braces form ${name} when the name touches other text.

Positional parameters hold the arguments passed to a script or function. $1 is the first argument, $2 the second, $0 is the script name, $# is the argument count, and $@ is all arguments.

Quote "$@" when passing arguments along, because it preserves each argument as a separate word even when values contain spaces. Unquoted $* joins everything into one string.

Every command returns an exit status: 0 for success, any non-zero value for a specific failure. The special variable $? holds the status of the last command that ran.

Scripts use exit status to make decisions: run the next step only if the previous one succeeded. Your own scripts should exit non-zero on failure so callers can detect it.

if runs a command and branches on its exit status; the [ ] test command (or the Bash [[ ]] keyword) evaluates a condition and returns 0 or non-zero. elif and else add branches, and fi closes the block.

Numeric comparisons use -eq, -lt, -gt; string comparisons use = and !=. Spaces inside the brackets are required, another common early bug.

for iterates over a list of words or a glob; while runs while a command succeeds; until runs while a command fails. C-style for ((i=0; i<5; i++)) also works in Bash.

The most common pattern is looping over files with a glob. Guard against no matches with nullglob or a test, because an unmatched glob stays literal by default.

The read builtin captures a line from standard input into one or more variables. read -p shows a prompt, read -s hides typing (for passwords), and read -r stops backslashes from being interpreted.

Almost always use read -r; the plain form mangles backslashes, which surprises people processing file paths.

Command substitution runs a command and replaces the expression with its standard output. The modern form is $(command); the older backtick form works but nests poorly and is harder to read.

It's how you capture output into a variable or feed one command's result into another line, like storing today's date or a file count.

echo prints arguments with a trailing newline and is fine for simple messages, but its handling of flags and escape sequences varies between shells and systems. printf gives you a format string with predictable escapes and field formatting.

For anything beyond a plain line, especially formatted numbers or reliable escapes across systems, printf is the safer choice.

Anything after a # to the end of the line is a comment, except inside quotes and except the shebang on line one. There's no block-comment syntax.

A common trick for a multi-line block is a heredoc sent to the no-op colon command, but most scripts just prefix each line with #.

Give the file execute permission with chmod +x script.sh, then run it as ./script.sh. Without execute permission you can still run it explicitly with bash script.sh.

The ./ prefix matters because the current directory usually isn't on PATH, which is a deliberate safety default so you don't run a stray script by name.

Strings use = and != (and < , > inside [[ ]] for lexical order). Numbers use -eq, -ne, -lt, -le, -gt, -ge. Mixing them up, like using -eq on strings, is a frequent bug.

Always quote string variables in a test so an empty value doesn't break the syntax. Inside [[ ]] the quoting is more forgiving, which is one reason it's preferred in Bash.

File test operators check attributes of a path: -f (regular file exists), -d (directory), -e (exists at all), -r / -w / -x (readable, writable, executable), and -s (exists and is non-empty).

They're how scripts decide whether to read a config, create a directory, or bail out early. Combine them with && or nest them in an if.

Wrap integer math in $(( )): result=$((3 + 4)). Inside the double parentheses you don't need $ on variable names, and you get the usual operators plus ++ and +=.

The shell only does integer math natively. For decimals, pipe through bc or use awk, since $(( )) truncates.

A pipe (|) sends one command's standard output into the next command's standard input, chaining tools into a stream. Redirection sends a stream to or from a file: > overwrites, >> appends, < reads input, and 2> captures errors.

This composition is the heart of shell work: small tools connected by pipes solve problems no single tool does alone.

Every process has three standard streams: stdin (0) for input, stdout (1) for normal output, and stderr (2) for error messages. Keeping errors on a separate stream lets you log or filter them independently of results.

That's why 2>&1 exists: it merges stderr into stdout so both go to the same place, useful when redirecting all output of a command to one log.

grep searches text for lines matching a pattern and prints them. Common flags: -i (ignore case), -v (invert, show non-matches), -r (recurse directories), -n (show line numbers), and -c (count).

grep -E turns on extended regex for alternation and grouping; grep -F treats the pattern as a fixed string, which is faster and avoids regex surprises when searching for literal text.

Globbing is the shell's filename expansion: * matches any run of characters, ? matches one character, and [abc] matches a character set. The shell expands globs before the command runs.

Globs are not regular expressions. * in a glob means 'any characters', but in regex it means 'zero or more of the previous item'. Confusing the two is a frequent source of bugs when moving between file matching and grep patterns.

Environment variables are name-value pairs passed to child processes. A plain assignment stays local to the current shell; export makes it visible to programs the shell launches. PATH, HOME, and USER are familiar examples.

Setting VAR=value command runs one command with that variable set, without changing your session, which is handy for one-off overrides.

$$ is the process id of the current shell, handy for unique temp names or logging. $! is the process id of the last command started in the background, which you use to wait on or signal it. $- lists the current shell option flags.

These sit alongside the argument variables ($0, $#, $@) and the exit status ($?). Knowing $! is what lets a script launch a background job and manage it later.

Use ${var:-default}, which yields default when var is unset or empty but doesn't change var. ${var:=default} also assigns the default back to var. The colon makes empty count as unset; drop it to treat only truly-unset as missing.

This is the clean way to handle optional arguments and environment overrides without a separate if block.

Define with name() { ... } and call it by name, passing arguments that appear inside as $1, $2, and so on. Functions share the script's variables unless you mark them local.

A function returns an exit status with return (0 to 255), not a value. To hand back data, echo it and capture with command substitution.

sed is a stream editor: it reads text line by line and applies edits, most often substitution with s/pattern/replacement/. It's the go-to for search-and-replace across a stream or file without opening an editor.

The g flag replaces every match on a line, not just the first; -i edits files in place; and & in the replacement re-inserts the matched text. sed works on whole streams, so it fits naturally in pipes.

awk is a text-processing language built around fields and records. It splits each line into fields ($1, $2, ...) and runs pattern-action rules, which makes column extraction, filtering, and quick aggregation one-liners.

Reach for awk when the data is columnar and you need arithmetic or grouping. It handles sums, averages, and per-key totals that grep and sed can't.

Use grep to find and print lines that match. Use sed to transform text, mostly substitution and line edits. Use awk when data is columnar and you need fields, arithmetic, or grouping.

They overlap, so the honest answer is about the simplest tool that fits: don't reach for awk to do a plain search, and don't chain five greps when one awk rule is clearer.

set -e exits on the first unhandled command failure, set -u treats unset variables as errors, and set -o pipefail makes a pipeline fail if any command in it fails, not just the last. Together they turn silent failures into loud, early exits.

It's the common safety header for production scripts. The caveat worth naming: set -e has surprising exceptions (commands in conditionals, for example), so it's a strong default, not a substitute for explicit error handling.

Bash indexed arrays are declared with arr=(a b c) and accessed by index ${arr[0]}. Expand all elements safely with "${arr[@]}" and get the count with ${#arr[@]}.

Associative arrays (declare -A) map string keys to values, which is Bash's dictionary. Both are Bash-only; plain POSIX sh has no arrays, worth flagging if portability matters.

Parameter expansion is the ${...} syntax that transforms a variable without calling external tools. It provides defaults, substring extraction, prefix and suffix removal, and search-and-replace, all inside the shell.

Using it instead of piping to sed or cut is faster and avoids a subprocess. The pattern operators (#, ##, %, %%) trim from the front or back, greedy or not.

A heredoc feeds a block of literal text to a command's standard input, ending at a chosen marker. It's how you embed multi-line content: a config file, an SQL query, an email body, without escaping each line.

Quote the opening marker ('EOF') to stop variable expansion inside the block; leave it unquoted to expand variables. The <<- variant strips leading tabs so you can indent the block.

trap runs a command when the script receives a signal or hits a pseudo-event. The common use is trap 'cleanup' EXIT, which guarantees a cleanup function runs whether the script finishes normally, errors out, or is interrupted.

It's how you remove temp files, release locks, or restore state reliably. Catching INT and TERM lets a long-running script shut down gracefully on Ctrl+C or a kill.

Running (./script.sh or bash script.sh) starts a new child shell, so any variables or directory changes vanish when it ends. Sourcing (source script.sh or . script.sh) runs the lines in your current shell, so its changes persist.

That's why you source environment files and activation scripts but execute normal programs. Sourcing a script that calls exit will close your current shell, a surprise worth knowing.

cut extracts columns by delimiter or character position; tr translates or deletes characters; sort orders lines; uniq collapses adjacent duplicate lines. Chained together they cover a lot of quick data shaping.

The key gotcha: uniq only removes adjacent duplicates, so you almost always sort first. sort -u does both in one step.

xargs reads items from standard input and builds them into arguments for another command. It bridges tools that produce a list (like find) with tools that take arguments (like rm or grep).

Use find ... -print0 | xargs -0 to handle filenames with spaces or newlines safely. -n limits arguments per call and -P runs calls in parallel.

find walks a directory tree and matches by name, type, size, time, or permission, then acts on the matches. -name globs the filename, -type f or d filters kind, -mtime filters by age, and -exec or a pipe to xargs runs a command per match.

-exec cmd {} + batches matches into fewer command calls, which is faster than the one-per-file + \; form for large trees.

case matches a value against patterns, which reads far cleaner than a long if/elif chain when branching on one variable. Each branch is a glob-style pattern ending in ;;, and *) is the catch-all default.

It's the standard shape for parsing a command argument or a menu choice, and patterns can use |, wildcards, and character classes.

Check exit status explicitly where you need to react: cmd || { echo 'failed' >&2; exit 1; }. Group cleanup in a trap on EXIT. Validate inputs early and exit with a clear message rather than letting a later command fail cryptically.

For a pipeline, remember only the last command's status is $? unless pipefail is set. Writing errors to stderr (>&2) keeps them out of captured output.

[ ] is the POSIX test command, portable but prone to word-splitting problems with unquoted variables. [[ ]] is a Bash keyword with safer parsing, pattern matching, regex via =~, and && / || inside. (( )) is for integer arithmetic and numeric comparisons.

In Bash scripts, use [[ ]] for string and file tests and (( )) for math. Fall back to [ ] only when the script must run under plain POSIX sh.

Process substitution, <(command), makes a command's output look like a file, so you can feed the output of one command where a filename is expected. The classic use is comparing two commands' output with diff without temp files.

It's a Bash feature (not POSIX sh) implemented with named pipes. It's the clean way to diff, join, or paste live command output.

cron is the classic scheduler: a crontab line has five time fields (minute, hour, day of month, month, day of week) followed by the command. crontab -e edits your jobs, and each line runs the command on that schedule.

Two production tips worth naming: cron runs with a minimal environment and PATH, so use absolute paths, and redirect output to a log or you'll miss errors. systemd timers are the modern alternative on many systems.

By default every variable in a shell script is global, so a variable set inside a function leaks out and can clobber one with the same name elsewhere. Declaring it with local scopes it to the function.

In any script with functions, local is the difference between reusable functions and mysterious action-at-a-distance bugs. It's Bash-specific but widely available.

Run it with bash -x script.sh (or add set -x inside) to trace every command with its expanded values, which shows exactly what the shell saw after expansion. set -v prints lines before expansion. bash -n does a syntax check without running.

For targeted tracing, wrap a section between set -x and set +x. Combined with set -u to catch unset variables, this finds most bugs quickly.

Use while IFS= read -r line; do ...; done < file. IFS= keeps leading and trailing whitespace, -r stops backslash mangling, and reading from a redirect avoids loading the whole file into memory.

Avoid for line in $(cat file): it splits on all whitespace, not newlines, and breaks on spaces and globs. The while-read idiom is the answer the question expects.

Target the POSIX shell feature set: use #!/bin/sh, avoid Bash-only constructs (arrays, [[ ]], process substitution, ${var^^}), and test with a strict shell like dash. Stick to [ ], printf over echo -e, and parameter expansion that POSIX defines.

The honest trade-off to name: portability costs convenience. Many teams standardize on Bash and #!/usr/bin/env bash instead, because the machines they run on all have it. Portability matters most for install scripts and containers with minimal shells.

After expansion, the shell splits unquoted results on the characters in IFS (space, tab, newline by default) and then expands globs. So an unquoted $file holding 'my report.txt' becomes two arguments, and a value containing * expands to matching filenames.

Quoting expansions ("$file", "$@", "${arr[@]}") turns off splitting and globbing, keeping each value intact. This one habit prevents the majority of real-world shell bugs, which is exactly why linters like shellcheck flag every unquoted expansion.

shellcheck is a static analyzer for shell scripts. It catches unquoted expansions, useless use of cat, wrong test operators, portability issues, and dozens of other bug classes before the script ever runs.

In a real workflow it runs in CI and in the editor, so problems surface at write time. Treating its warnings as errors is the fastest way to raise a team's shell quality, and it matters.

Trap the signals you care about: INT (Ctrl+C), TERM (default kill and container stop), and HUP. In the handler, stop accepting new work, finish or abort in-flight work, release resources, and exit with a status that reflects the signal.

For a script that manages child processes, forward the signal to the children and wait for them, otherwise orphaned processes linger. In containers, handling TERM is what lets your process shut down cleanly before the runtime sends KILL.

Use mktemp, which creates a file (or directory with -d) with a random, unpredictable name and safe permissions, then returns its path. Never build a temp name from $$ or a fixed string, because that invites race conditions and predictable-name attacks.

Pair mktemp with a trap on EXIT to remove it on every exit path. For directories, mktemp -d gives a private workspace you clean up in one rm -rf.

A subshell is a child copy of the current shell, created by parentheses ( ... ), each side of a pipe, and command substitution. Changes to variables inside a subshell don't propagate back to the parent, which is a frequent surprise.

The classic bug: piping into a while loop runs the loop in a subshell, so counters set inside it are lost afterward. Fixes are process substitution or lastpipe. Spawning many subshells in a hot loop also costs measurable time versus a single tool call.

The shell does integer arithmetic only; $(( )) truncates. For decimals, pipe an expression to bc (with a scale for precision) or use awk, which has full floating-point built in and is usually the cleaner choice inside a pipeline.

For anything beyond a couple of calculations, that's often the sign to move the logic to a language with real numeric types rather than fighting bc syntax.

getopts is the built-in for short options: it loops through flags, sets a variable to each option letter, and puts an argument in OPTARG when the option string marks it with a colon. It handles bundling and stops at the first non-option.

For long options (--verbose), getopts doesn't help; teams either use a manual while/case loop or an external getopt. Naming that limitation shows you've built a real CLI, not just a demo.

An idempotent script produces the same end state whether it runs once or many times: it checks before it acts (mkdir -p, test before create, append only if missing) instead of assuming a clean slate. Running it twice doesn't duplicate or break anything.

It matters for automation and configuration management, where scripts rerun on retries, cron, or partial failures. A non-idempotent deploy that appends a line every run is a classic production bug.

0 means success, 1 to 125 are application-defined failures, 126 means the command was found but not executable, 127 means command not found, and 128+n means the process was killed by signal n (so 130 is Ctrl+C, SIGINT). Codes above 255 wrap around.

Well-behaved scripts return distinct non-zero codes for distinct failure modes, so callers and monitoring can react differently. Reserving a small set of meaningful codes beats returning 1 for everything.

Stream it, never load it. Pipe through line-oriented tools (awk, sed, grep) that read one record at a time so memory stays flat regardless of file size. Prefer a single awk pass over chaining many tools, since each stage is another process reading the whole stream.

For CPU-bound work, split the file and process chunks in parallel with xargs -P or GNU parallel. And know when to stop: past a certain complexity, a streaming program in Python or Go is more maintainable than a heroic awk script.

Use a lock. flock ties an advisory lock to a file descriptor and releases it automatically when the script exits, which avoids stale locks from a plain if-file-exists check that a crash would leave behind. Wrapping the script in flock -n on a lock file is the clean pattern.

The manual mkdir-as-lock trick works because directory creation is atomic, but flock is safer because it self-releases. This comes up for cron jobs that might overlap when one run runs long.

The big ones: unquoted expansions that allow injection or unexpected globbing, passing untrusted input to eval or a shell, predictable temp file names, secrets in the script or in ps output, and a permissive PATH that lets an attacker shadow a command.

Defenses: quote everything, avoid eval on data you don't control, use mktemp, read secrets from the environment or a secret store rather than arguments (which are visible in ps), and set an explicit PATH at the top of privileged scripts.

Switch when logic outgrows the shell's strengths: complex data structures, non-trivial parsing, math beyond integers, code that needs unit tests, error handling that must be precise, or a script pushing past a few hundred lines. Those are the signs the shell is fighting you.

The shell stays the right tool for gluing commands, file operations, and short automation. The senior instinct is recognizing the crossover early, before a 400-line Bash script becomes the thing nobody wants to touch.

Beyond signals, trap can fire on the ERR pseudo-signal (when a command fails under set -e) to print context, and on DEBUG before every command. A trap on ERR that reports the failing line and command turns a silent set -e exit into an actionable message.

Combining trap ERR with $LINENO and BASH_COMMAND gives you a lightweight backtrace, which is the kind of self-diagnosing script that saves hours in production.

eval takes a string, expands it a second time, and runs the result as a command. That extra expansion is exactly the danger: any untrusted content in the string can inject arbitrary commands, so eval on data you don't fully control is a security hole.

Legitimate uses are rare and narrow, like reifying dynamically named variables. Most cases people reach for eval are better solved with arrays, indirect expansion (${!name}), or restructuring the code so no second evaluation is needed.