Command Line and Shell Scripting Questions

Practical skills using command line interfaces and writing simple shell scripts for automation and system administration across operating systems. For Linux this includes navigation and file operations, file permissions, process and service inspection, log viewing, package and systemctl management, common text processing and search utilities such as grep, find, sed, and awk, piping and redirection, environment variables, command substitution, and interactive use of editors and remote access tools. Shell scripting fundamentals include variables, conditionals, loops, functions, argument handling, basic debugging, and using bash to automate repetitive tasks. The scope also covers essential Windows command line and shell basics where relevant, including interactive commands, simple PowerShell cmdlets for process and service management, file and permission commands, and differences in syntax and environment when performing equivalent administrative tasks on Windows. Candidates may be evaluated on writing short scripts, composing command pipelines to accomplish tasks, and explaining tradeoffs between interactive commands and scripted automation.

EasyTechnical

86 practiced

Explain the Linux file permission and ownership model: user/group/other, rwx bits and numeric modes. Given a dataset directory that should allow group access to 'data' group but deny world access, provide the commands to set permissions, change ownership to user 'etl' and group 'data', set a setgid bit so new files inherit the group, and explain edge cases (umask, ACLs).

Sample Answer

Linux permissions are split into owner (user), group, and others (world). For each there are three bits: read (r=4), write (w=2), execute/traverse (x=1). Numeric mode is the sum per class: e.g., 750 means owner=rwx(7), group=r-x(5), others=---(0).

For a dataset directory that should be owned by user etl, group data, allow full group access but deny world, and ensure new files inherit the group, do:

- Change ownership:

bash

sudo chown -R etl:data /path/to/dataset

- Set directory permissions so owner rwx, group rwx, others none (770 numeric), applied recursively for directories and files (files usually should be 660):

bash

# Directories: rwxrws--- (2770) — setgid bit (2) ensures new files/dirs inherit the group
sudo find /path/to/dataset -type d -exec chmod 2770 {} +

# Files: rw-rw---- (660)
sudo find /path/to/dataset -type f -exec chmod 660 {} +

Alternatively set the top directory then new children will inherit group and default perms influenced by umask:

bash

sudo chown etl:data /path/to/dataset
sudo chmod 2770 /path/to/dataset

Notes and edge cases:- setgid on a directory (the leading 2 in 2770) makes new files/dirs inherit the directory’s group, not the creating user's primary group.- umask controls default permission bits for newly created files (commonly 002 or 022). With umask 002 and default creation, files become 664 and dirs 775; with umask 007 you get group but no others. Ensure service/account umask allows group write if needed (set in systemd unit or shell profile).- ACLs (getfacl/setfacl) can provide finer-grained access. If ACLs exist they can override or augment basic permission semantics. Check existing ACLs:

bash

getfacl /path/to/dataset

- If you rely on ACLs to grant group rights to subgroups, remember to set default ACLs on the directory so new files inherit them:

bash

sudo setfacl -R -m d:g:data:rwx /path/to/dataset   # default ACL for group 'data'

- Be careful with sticky bits and NFS mounts (some NFS setups ignore setgid or map UIDs/GIDs differently).

This setup ensures etl and members of group data have read/write/execute (traverse) access while world has no access; setgid and appropriate umask/ACLs ensure future files inherit the intended group and permissions.

EasyTechnical

90 practiced

Write a small POSIX-compatible bash script named `checkfile.sh` that accepts a single filename argument and prints whether the file exists, is readable, writable, executable, and its size in bytes. Include usage instructions and exit codes for the following conditions: missing arg, not found, success.

Sample Answer

Approach: use a POSIX /bin/sh script that checks argument presence, then tests file existence and permissions with [ -e ], [ -r ], [ -w ], [ -x ] and prints file size with wc -c (portable) or stat fallback.

#!/bin/sh
# checkfile.sh - POSIX-compatible file checks
# Usage: checkfile.sh <filename>
# Exit codes:
#   2 - missing argument
#   3 - file not found
#   0 - success

if [ $# -ne 1 ]; then
  printf 'Usage: %s <filename>\n' "$0" 1>&2
  exit 2
fi

file=$1

if [ ! -e "$file" ]; then
  printf 'File not found: %s\n' "$file" 1>&2
  exit 3
fi

printf 'File: %s\n' "$file"

if [ -r "$file" ]; then printf 'Readable: yes\n'; else printf 'Readable: no\n'; fi
if [ -w "$file" ]; then printf 'Writable: yes\n'; else printf 'Writable: no\n'; fi
if [ -x "$file" ]; then printf 'Executable: yes\n'; else printf 'Executable: no\n'; fi

# POSIX way to get size: wc -c (handles pipes safely)
size=$(wc -c < "$file" 2>/dev/null)
printf 'Size (bytes): %s\n' "${size:-0}"

exit 0

Key points:- Uses POSIX tests and avoids non-portable stat flags.- wc -c reads bytes; for special files size may be 0 or block device-specific.Edge cases:- Directories: permissions reflect directory bits; wc -c on directories may fail (returns 0).- Binary or large files handled by wc.

MediumTechnical

91 practiced

Explain what `set -euo pipefail` does in bash scripts. Provide an example where omitting these flags causes a subtle bug (such as ignoring a failing command in a pipeline) and show how enabling them changes script behavior. Also explain how to allow a specific command to fail without exiting.

Sample Answer

set -euo pipefail is a common trio of bash options that makes scripts fail-fast and safer:

- -e: exit immediately if any simple command returns non-zero (prevents continuing after errors).- -u: treat unset variables as errors and exit (avoids silent typos / missing env vars).- -o pipefail: returns the exit status of the rightmost failing command in a pipeline (instead of the pipeline's last command), so pipeline failures aren't hidden.

Example (subtle bug when omitted):

bash

#!/usr/bin/env bash
# no set -euo pipefail

rm -f /tmp/mydata.csv
# simulate a failed download (curl returns non-zero)
curl -sSf http://example.invalid/data.csv | gzip -d > /tmp/mydata.csv
# process file only if exists
if [ -s /tmp/mydata.csv ]; then
  echo "Processing data"
  # ... processing steps ...
else
  echo "No data, but continuing"  # script continues silently
fi

If curl fails, without pipefail the pipeline's exit status is that of gzip (which may succeed/fail differently) and the script may continue, treating /tmp/mydata.csv as absent or stale — causing downstream jobs to run on wrong assumptions.

With strict options:

bash

#!/usr/bin/env bash
set -euo pipefail

rm -f /tmp/mydata.csv
curl -sSf http://example.invalid/data.csv | gzip -d > /tmp/mydata.csv
# if curl fails, script exits immediately; no silent continuation

Now the failing curl causes immediate exit, surfacing the error to orchestration (Airflow, cron, CI) so the issue can be retried or investigated.

Allowing a specific command to fail- Use command || true to tolerate failure without exiting: curl ... || true- Or temporarily disable -e for a block: set +e may_fail_command rc=$? set -e # handle $rc explicitly

Prefer explicit handling (check return code) rather than suppressing errors globally. For pipelines where you expect non-zero from an earlier stage, handle that command separately or use || true with careful logging. This pattern helps data pipelines fail fast on real errors while allowing controlled exceptions.

MediumTechnical

94 practiced

Implement a bash script using `getopts` that accepts `-i input_file -o output_file -v (verbose) -h (help)`. The script should validate that the input exists and output directory is writable and should print usage and exit codes on invalid arguments. Provide the implementation sketch.

Sample Answer

Approach: use getopts to parse flags, validate required args, check input exists and is readable, check output directory exists and is writable (or create if desired), support -v for verbose and -h for usage. Exit codes: 0 success, 1 usage/invalid args, 2 missing/invalid file, 3 permission errors.

bash

#!/usr/bin/env bash

set -euo pipefail

usage() {
  cat <<USAGE
Usage: $(basename "$0") -i input_file -o output_file [-v] [-h]
  -i  Path to input file (must exist and be readable)
  -o  Path to output file (directory must be writable)
  -v  Verbose mode
  -h  Show this help
Exit codes:
  0  Success
  1  Invalid arguments / usage
  2  Missing or unreadable input file
  3  Output directory not writable
USAGE
}

verbose=false
input=""
output=""

# Parse options
while getopts ":i:o:vh" opt; do
  case $opt in
    i) input=$OPTARG ;;
    o) output=$OPTARG ;;
    v) verbose=true ;;
    h) usage; exit 0 ;;
    \?) echo "Invalid option: -$OPTARG" >&2; usage; exit 1 ;;
    :) echo "Option -$OPTARG requires an argument." >&2; usage; exit 1 ;;
  esac
done

# Validate required args
if [[ -z "$input" || -z "$output" ]]; then
  echo "Both -i and -o are required." >&2
  usage
  exit 1
fi

$verbose && echo "Input: $input"
$verbose && echo "Output: $output"

# Check input exists and readable
if [[ ! -f "$input" || ! -r "$input" ]]; then
  echo "Input file '$input' does not exist or is not readable." >&2
  exit 2
fi

# Check output directory writable
outdir=$(dirname "$output")
if [[ ! -d "$outdir" ]]; then
  echo "Output directory '$outdir' does not exist." >&2
  exit 3
fi
if [[ ! -w "$outdir" ]]; then
  echo "Output directory '$outdir' is not writable." >&2
  exit 3
fi

$verbose && echo "Validation passed. Proceeding with processing..."

# Example processing: copy input to output
cp -- "$input" "$output"
$verbose && echo "Copied '$input' to '$output'"

exit 0

Key points:- Use getopts with proper error handling for missing args.- Validate file existence/readability and directory writability.- Provide clear usage and specific exit codes for automated pipelines.- Consider enhancing to create output directory (with confirmation) or support relative paths.

MediumTechnical

126 practiced

Write a PowerShell script that queries the Windows 'Application' event log for Error and Warning entries from the last 48 hours, filters by ProviderName 'MyETL', and exports results to a CSV with columns TimeCreated, LevelDisplayName, Message, and Computer. Also show how to produce a count of errors per machine.

Sample Answer

Approach: Use Get-WinEvent to query the Application log with a time filter and level filter, then select required properties and export to CSV. Use Group-Object to produce per-machine error counts.

powershell

# Query Application log for Errors(2) and Warnings(3) in last 48 hours from provider "MyETL"
$since = (Get-Date).AddHours(-48)

$filterHash = @{
    LogName = 'Application'
    ProviderName = 'MyETL'
    StartTime = $since
    Level = @('2','3')  # 2 = Error, 3 = Warning
}

# Get events
$events = Get-WinEvent -FilterHashtable $filterHash -ErrorAction Stop

# Project desired columns and export to CSV
$exportPath = "C:\tmp\MyETL_Events_Last48h.csv"

$events |
    Select-Object @{
        Name='TimeCreated'; Expression = {$_.TimeCreated}
    }, @{
        Name='LevelDisplayName'; Expression = {$_.LevelDisplayName}
    }, @{
        Name='Message'; Expression = {$_.Message -replace '\r?\n',' '} # flatten newlines
    }, @{
        Name='Computer'; Expression = {$_.MachineName}
    } |
    Export-Csv -Path $exportPath -NoTypeInformation -Encoding UTF8

Write-Output "Exported $($events.Count) events to $exportPath"

# Produce a count of ERRORs per machine (only Level = Error)
$errorsPerMachine = $events |
    Where-Object { $_.LevelDisplayName -eq 'Error' } |
    Group-Object -Property MachineName |
    Select-Object @{Name='Computer';Expression={$_.Name}}, @{Name='ErrorCount';Expression={$_.Count}} |
    Sort-Object -Property ErrorCount -Descending

Write-Output "Errors per machine:"
$errorsPerMachine | Format-Table -AutoSize

Key points:- Get-WinEvent is preferred over Get-EventLog for performance and advanced filtering.- Use FilterHashtable for server-side filtering (faster).- Flatten message newlines before CSV to avoid breaking rows.- Group-Object gives per-machine aggregation; can output to CSV if needed: $errorsPerMachine | Export-Csv ...

Edge cases:- ProviderName must match exactly; consider partial matches by filtering on Message or ProviderName with Where-Object if needed.- Permissions: script may need elevated rights to read remote logs.- Large result sets: consider streaming to CSV (pipe directly without storing $events) or using -MaxEvents to limit.

Alternative:- For remote machines, use Invoke-Command or Get-WinEvent -ComputerName (supported on some systems) and aggregate centrally.

Unlock Full Question Bank

Get access to hundreds of Command Line and Shell Scripting interview questions and detailed answers.

Join thousands of developers preparing for their dream job.