70+ Linux Scripting Interview Questions & Answers (2026)

Answer: A shell script is a text file containing commands that the shell executes sequentially. It automates repetitive tasks, improves efficiency, and ensures consistency across executions.

The shebang (#!): The first line of a shell script. Examples:

• #!/bin/bash — Use Bash shell (most common)
• #!/bin/sh — Use POSIX sh (more portable, fewer features)
• #!/usr/bin/env python3 — Use Python 3 interpreter
• #!/bin/zsh — Use Zsh shell

Why shebang matters: Without it, the system doesn’t know which interpreter to use. The kernel reads the shebang and executes the appropriate interpreter. Always use #!/bin/bash unless you need POSIX portability.

Answer:

When to use: Use #!/bin/sh for system startup scripts and scripts that must run on all Unix systems. Use #!/bin/bash for Linux-only scripts where you want arrays, functions, and advanced features. In practice, most modern Linux scripts use Bash.

Answer: Every command returns an exit status (exit code) from 0 to 255. $? stores the exit status of the last command.

• Exit status 0 = Success
• Exit status 1–255 = Failure (meaning varies by command)
• $? is set immediately after a command, so capture it right away if needed

Better approach: Use || (or) and && (and) operators: cp file.txt /tmp/ || exit 1

Answer:

Best practice: Use double quotes for most strings to allow variable expansion. Use single quotes only when you want literal text. Always quote variables: "$var" not $var to prevent word splitting.

Answer: Three ways to do arithmetic, each with pros/cons:

• $((expression)) — FASTEST, PREFERRED Built-in Bash arithmetic. No external command. Supports +, -, *, /, %, ++, –. Example: result=$((10 + 5)). Use this 99% of the time.
• expr — SLOWER External command, slower than $(()). Legacy syntax. Example: result=$(expr 10 + 5). Spawns a process. Avoid unless you need portability to ancient systems.
• bc — FOR DECIMAL/ADVANCED MATH Floating-point calculator. Example: result=$(echo "10.5 + 3.2" | bc). Use only for decimals or complex math ($(()) handles integers only).

Interview answer: “I’d use $(()), which is Bash built-in and fastest. For floating-point math, I’d use bc. I avoid expr because it’s slower and mostly obsolete.”

Answer: Test operators for conditionals:

• Integer comparison: -eq (equal), -ne (not equal), -lt (less than), -gt (greater than), -le, -ge
• String comparison: = (equal), != (not equal), -z (empty string), -n (non-empty)
• File testing: -f (file exists), -d (directory exists), -e (any file exists), -r (readable), -w (writable), -x (executable), -s (file has size)
• Logical operators: && (and), || (or), ! (not)

[ ] vs [[ ]]: Use [ ] for POSIX portability (sh scripts). Use [[ ]] for Bash (allows wildcards, no quote splitting). [[ ]] is safer for most use cases.

Answer:

Key points: Always quote variables ("$FILE"). Use && for multiple conditions. Use elif for additional checks. Handle all cases (exists, not readable, doesn’t exist).

• Practical problem-solving: They’ll ask you to write code. Write clean, readable scripts with comments. Test edge cases (empty input, special characters, missing files).
• Error handling: Show you check exit codes and handle errors gracefully. Use set -e or || exit 1 to fail fast.
• Best practices: Quote variables, use meaningful names, avoid hardcoding, add logging. These show maturity.
• Performance awareness: Avoid unnecessary loops, use built-ins over external commands, explain trade-offs (speed vs readability).
• Real-world experience: Tell stories about scripts you’ve written. Backup automation? Log monitoring? Deployment? Link your answers to production scenarios.
• Ask clarifying questions: “Is this for a Linux-only environment or should it be portable?” “What’s the expected file size?” “How should I handle errors?” Real engineers clarify requirements before coding.

• Not testing your code: Write it, run it, show it works. Silent failures are red flags.
• Ignoring edge cases: What if the file is empty? What if the user passes no arguments? Handle it.
• Hardcoding paths/values: Use variables and configuration files. Shows thinking about reusability.
• Using obsolete syntax: Backticks instead of $(), expr instead of $(()), [ ] when [[ ]] is better. Interviewers notice.
• Not explaining your logic: Code silently is boring. Talk through it: “I’m checking if the file exists, then verifying it’s readable, then processing it.”
• Claiming expertise you don’t have: It’s fine to say “I haven’t used awk much, but I understand the concept.” Interviewers respect honesty.