Create simple shell scripts practice questions

if grep -q '^jdoe:' /etc/passwd; then echo 'Exists'; else useradd 'jdoe' && echo 'Created'; fi

Why it fails: useradd without -m does not create home directory.

if ! id 'jdoe' &>/dev/null; then useradd -m 'jdoe'; else echo 'Exists'; fi

Why it fails: Logic inverted: if user does NOT exist, create; else echo. But no verification of success.

[ -z $(id 'jdoe' 2>/dev/null) ] && useradd -m 'jdoe' && echo 'Created'

Why it fails: [ -z ] checks if the output is empty, but the command substitution may not work as expected; also no error handling.

The script is not executable and is run with `sh script.sh`, causing the shebang to be ignored.

Why it fails: Even though running `sh script.sh` causes the shebang line to be treated as a comment, the rest of the script still executes normally under sh. The bug lives in the script body: `[ systemctl status httpd ]` is a test command that always succeeds because it evaluates a non-empty string. Changing the execution method or making the script executable would not affect this behavior, so this is not the root cause.

The variable SERVICE is misspelled as "HTTPD" in the condition.

Why it fails: The exhibit shows the variable SERVICE spelled consistently with the same capitalization in both its assignment and its use in the condition. Shell variables are case-sensitive, so a mismatch like `HTTPD` versus `SERVICE` would yield an empty variable and not necessarily produce an always-true condition. Since no misspelling exists, this explanation cannot account for the observed problem.

The `systemctl` command requires root privileges, and the script is run as a non-root user.

Why it fails: The stem explicitly states that the script is run as root, so lack of privilege cannot be the issue. Furthermore, the same failure would occur for any user because the problem is not permission denial — it is the `[` command that subverts the condition. If the script directly used `systemctl status httpd` as the condition, the exit code would be evaluated correctly regardless of the calling user, making this rationale incorrect.

The PATH variable in cron does not include /usr/bin/rsync. Add a full path to rsync in the script or set PATH in the crontab.

Why it fails: The error message 'Host key verification failed' is produced by the SSH client after rsync has already spawned a remote shell connection; it does not indicate that rsync itself is missing. If rsync were absent from cron's PATH, you would see a 'command not found' error in the cron mail or syslog, not an SSH host key error. Moreover, even if you add /usr/bin/rsync explicitly, SSH's host key verification is performed before the remote rsync process starts, so altering PATH would not change the SSH handshake outcome. Thus, the root cause is unrelated to rsync's location.

The script does not have execute permission for the root user. Run `chmod +x /opt/scripts/sync_configs.sh`.

Why it fails: Cron executes scripts as the user listed in the crontab, and when that user is root, the script's ownership and mode are checked against root's effective UID. Since the script is owned by root, a typical file mode such as 755 or even 700 would grant execute permission to root, so 'permission denied' would not occur. Furthermore, the presence of an SSH host key error proves the script did run: if the script lacked execute permission, cron would report the failure before executing any commands, and you would never see SSH-related output. Therefore, the permission diagnosis is contradicted by the observed behavior.

The known_hosts file in /root/.ssh/ contains an incorrect host key for the master server. Remove the entry and reconnect manually to update it.

Why it fails: The host key verification fails because SSH is not using the known_hosts file, not because the key is wrong. The error suggests the key is not being accepted because the host key is not known (i.e., not found) due to environmental issues.

dnf update: Installs a package with dependencies

Why it fails: dnf update is intended to upgrade all packages already present on the system to newer versions available in the repositories, not to introduce new packages. Installing a package with all its dependencies is dnf install, which first checks whether the package is already installed; update only applies to installed packages. While dnf update can replace a package with a newer build, it never performs the initial installation.

dnf search: Removes a package

Why it fails: dnf search performs a read-only query against repository metadata, matching an expression against package names, summaries, and descriptions, and prints a list of candidates without changing any installed files. Nothing is installed, removed, or even downloaded. Removing a package requires dnf remove, which reverses the transaction and deletes the associated files; search is purely informational.

The script must be sourced (.) instead of executed to retain variables

Why it fails: Sourcing a script with the '.' command runs it in the current shell, which would preserve top-level variables after the script ends. However, it does not affect the scoping rules of variables declared with 'local' inside functions: a local variable is still confined to that function's execution regardless of whether the script is sourced or executed. The issue is specifically that the 'local' keyword restricts the variable's visibility to the function, so sourcing cannot fix it.

The function was called inside a subshell, use 'export' to make it global

Why it fails: The variable's invisibility stems from the 'local' declaration, not from execution in a subshell; even if the function were invoked in a subshell, the 'local' variable would already be unavailable in the parent shell. 'export' only marks a variable for propagation to child processes; it does not promote a local variable into the current shell's global scope. Since the script is not necessarily running in a subshell, and export cannot cross the function boundary, this option is incorrect.

In bash, variables declared in a function are local by default, use 'declare -g' to make them global

Why it fails: Incorrect. In Bash, variables are global by default unless declared with 'local'. The statement 'variables declared in a function are local by default' is false. Using 'declare -g' is a valid way to ensure global scope, but the premise of the option is wrong.

The log files are already compressed (.gz extension), and gzip fails silently

Why it fails: Incorrect. The script targets .log files, not .gz files. Even if a file were already compressed, gzip would output an error (e.g., "gzip: ... has .gz suffix — ignored") but does not silently fail. Therefore, this is not the primary reason.

The script lacks proper quoting around {} which causes gzip to fail on files with spaces

Why it fails: Incorrect. While failing to quote {} can cause issues with filenames containing spaces, the command as written works for most filenames (no spaces). The problem statement says "some files" are not compressed, but it does not specify they have spaces. The more likely cause is the race condition, which affects any file regardless of spaces.

The '-mtime +30' flag selects files newer than 30 days, so old files are excluded

Why it fails: The -mtime +30 option does not skip old files; it selects them. In find, -mtime +30 matches files whose modification time is more than 30*24 hours ago, i.e., older than 30 days, so the oldest log files are precisely the ones that get passed to gzip. Such files are expected to be compressed by this rotation script, not left out. Conversely, -mtime -30 would match newer files, and -mtime 30 would match exactly 24 hours around the 30-day mark. Therefore, misreading the sign of the time comparator does not explain why any files are left uncompressed.

Use 'stdbuf -i0' before the script invocation to set stdin unbuffered

Why it fails: `stdbuf -i0` sets the standard input stream to unbuffered mode via the `stdbuf` wrapper, which alters how libc buffers reads from the file descriptor but does not change where that descriptor points. In a pipeline, stdin is still connected to the pipe, so `read` will still encounter EOF as soon as the pipe's writer finishes; unbuffered I/O only affects timing or granularity of reads, not the source. This option fails because it addresses buffering behavior, not the underlying problem of the script not having the terminal as its stdin.

Use 'read -t 0 input' to force immediate read

Why it fails: The `-t 0` option sets a timeout of zero seconds, which makes `read` return immediately without attempting to wait for input—the opposite of forcing a wait. With `read -t 0 input`, if no data is already available on stdin, the command exits with a non-zero status and `input` remains empty, so the script never gets user input. This approach is equivalent to a non-blocking read, and it does not redirect the source or extend a wait, making it categorically incorrect for this scenario.

bash script.sh

Why it fails: Running a script with bash does not make it executable; it simply passes the script as an argument to the bash interpreter.

. script.sh

Why it fails: Sourcing a script with . (dot) does not change file permissions; it reads and executes the script in the current shell.

chmod +x script.sh

Why it fails: chmod +x adds execute permission for all users, making the script executable, and is one of the two correct answers.

count=$(ls -1A | wc -l)

Why it fails: This pipeline lists every entry in the current directory with -1A, which reveals hidden entries but still includes directories, symlinks, sockets, and other non-regular file types, so it overcounts the number of regular files. Additionally, wc -l counts line breaks, so any filename containing a newline is split across multiple lines, producing an inflated count. The -A flag only removes . and .., not the need to filter by file type.

count=$(stat -c%F * | grep -c 'regular file')

Why it fails: The glob * does not match hidden files, so any dotfiles in the directory are silently excluded, producing an undercount. In an empty directory, * is left unexpanded and stat fails with an error, making the command unreliable. While stat -c%F outputs a token per file and grep -c counts exact 'regular file' matches, this version ignores hidden files and cannot handle the no-match case gracefully.

count=$(ls -1 | wc -l)

Why it fails: Omitting -a or -A means ls -1 skips all hidden files, unlike the -1A variant, so this undercounts when dotfiles exist while still overcounting because directories and other non-regular entries are included. The wc -l approach also breaks if any filename contains an embedded newline, splitting one entry across multiple lines. It is a classic example of why parsing ls output is fragile.

Change the loop to `for username in $(cat /tmp/users.txt)`.

Why it fails: Switching to a for loop with command substitution does not solve the problem because unquoted $(cat /tmp/users.txt) undergoes word splitting on every IFS character, so a line containing 'john doe' becomes two separate iteration values 'john' and 'doe'. Additionally, command substitution strips trailing newlines and can trigger pathname expansion on wildcard characters in the list. The while read construct is line-oriented and avoids these pitfalls.

Quote $username in the mkdir command as in `mkdir "/home/$username"`.

Why it fails: Quoting the variable in the mkdir command only protects the expanded value from further word splitting during command execution; it does not change how read assigned $username. Because the default read command splits the incoming line on IFS whitespace, $username receives only the first word, such as 'john' when the line is 'john doe'. The subsequent quoted mkdir then attempts to create /home/john, silently ignoring the rest of the intended name.

Add `set -f` to disable pathname expansion.

Why it fails: Using set -f disables pathname expansion (globbing), but the problem is word splitting, a distinct shell behavior that breaks the line into separate fields during read. Even with globbing disabled, read still splits on IFS, so the variable only captures the first word of a multi-word line. The correct fix is to set IFS= and use -r with read, not to modify glob options.

The PATH variable in cron is not set, so cp cannot be found.

Why it fails: The default PATH in cron is minimal but typically includes /usr/bin:/bin, where cp is installed by default on Red Hat systems. A script executed by cron therefore locates cp without requiring any special PATH modification. Moreover, a backup script could safely call /bin/cp with an absolute path, so this cannot be the reason the backup is not created.

The script does not have execute permission for the user running cron.

Why it fails: Cron does not require a script file to be executable if the crontab entry invokes an interpreter explicitly, such as /bin/bash /path/to/script, which is a common and robust pattern. Since the question states that the script is already running daily via cron, a missing execute bit would prevent it from running at all, not just make the backup fail. The real problem must occur after the script starts executing.

The cron job is not enabled because the crontab syntax is incorrect.

Why it fails: If the crontab syntax were invalid, crond would log a parse error and would not install the job, so the script would never run. The question explicitly says the script runs daily, which confirms the crontab entry is valid and enabled. An invalid crontab could not be the cause of a missing backup when the job is demonstrably executing.

Use #!/bin/sh for compatibility, even if bash-specific features are needed.

Why it fails: The shebang line must name the interpreter that actually executes the script; on modern Debian/Ubuntu systems /bin/sh is dash, a POSIX-only shell lacking bash arrays, [[ ]], and process substitution. Declaring #!/bin/sh while using bashisms leads to runtime syntax errors or unexpected behavior. For compatibility with bash features, explicitly use #!/bin/bash or, better, write POSIX-compliant code if portability is required.

Always run scripts by invoking the interpreter directly (e.g., bash script.sh) instead of making them executable.

Why it fails: Running a script with bash script.sh works, but it skips the shebang and negates the purpose of making the file executable, which is required for it to be invoked by name from PATH with ./script.sh. The executable bit and shebang together allow the kernel to select the correct interpreter automatically, and they are the standard for distributing scripts. Requiring users to know the interpreter reduces portability and convenience.

Scripts must be stored in /usr/local/bin to be found by the shell.

Why it fails: Scripts do not need to be stored in /usr/local/bin; the only requirement for the shell to find a script by name is that the script's directory is in the PATH environment variable. The shell searches PATH entries left to right, so placing a script in /usr/local/bin is just one convenient default, but any PATH-listed directory works. If a script is not in any PATH directory, you can still execute it by giving an explicit path like ./script or /home/user/bin/script. Thus there is no mandated location; only PATH inclusion or an explicit path determines whether the shell can find and run it.

A script must be compiled before it can be run.

Why it fails: Shell scripts are interpreted, not compiled. The interpreter named in the shebang reads and executes the script line by line, performing syntactic and semantic processing at runtime, rather than translating the source into a separate binary or bytecode file. Compiled languages such as C or C++ require a separate compilation step that produces an executable object, but that does not occur for shell scripts. Even if you see "syntax error" messages, they are raised by the interpreter during parsing, not because of a failed compilation. Consequently, there is never a "compilation required" step before running a shell script.

A script must have a .sh file extension to be executable.

Why it fails: The .sh file extension is purely a naming convention and has no effect on whether a file can be executed. The system determines a file is executable by the presence of execute permission bits, and it determines how to run a script by inspecting the shebang line at the beginning of the file. A script named backup, script.xyz, or even myscript.txt will execute identically to backup.sh as long as it contains the proper shebang and has execute permission. The extension is intended for humans and editors, not for the shell or kernel, so omitting .sh never prevents execution.

Change the shebang line to '#!/bin/sh' because bash is not the default shell.

Why it fails: Altering the shebang from #!/bin/bash to #!/bin/sh addresses nothing related to the reported symptom, because the script is not failing due to an invalid interpreter. The shebang merely tells the kernel which interpreter to launch; if bash is installed at /bin/bash, this line is perfectly valid. Furthermore, the absence of execute permission causes a 'Permission denied' error regardless of what the shebang says, so changing it would leave the exact same failure. The real correction is to add the execute bit to the file's mode.

Move the script to /usr/local/bin so it can be found in the PATH.

Why it fails: Relocating the script to /usr/local/bin would only affect how the script is found when typed as a bare command name (via the PATH search order). In this scenario the user is invoking the script by its full path (e.g., /home/devops/deploy.sh) or from its containing directory, so PATH resolution is completely bypassed and the file's current location is already reachable. More importantly, moving the file does not modify its permission bits; the script would still lack the necessary execute bit and continue to fail. Therefore, this action does not resolve the underlying permission problem.

Change the owner of the script to root using 'chown root:root /home/devops/deploy.sh'.

Why it fails: Changing ownership to root:root is entirely counterproductive here because the problem is not about ownership or group membership. The user already has read and write access as the owner, and those permissions are not blocking execution; the missing execute bit is the sole cause. Worse, giving the file to root would remove the user's write permission (unless group or other write were set), potentially breaking future edits, and it would still not set the execute bit. Ownership changes do not affect the kernel's permission check for execution unless the ACLs or mode are simultaneously altered, so this would leave the original error intact.

Mount snapshot to a directory, Create snapshot using lvcreate -s, Perform operations on snapshot, Unmount snapshot, Remove snapshot

Why it fails: This order fails at the outset because a logical volume snapshot is not an existing device until lvcreate -s has created it; mount only works against a valid block device path such as /dev/vg/origin-snap. Flipping the first two steps means the system cannot resolve the snapshot device, so the mount command returns an error and no subsequent snapshot operation can proceed. The snapshot must be created from the origin volume first, with the snapshot LV appearing as a separate device.

Create snapshot using lvcreate -s, Perform operations on snapshot, Mount snapshot to a directory, Unmount snapshot, Remove snapshot

Why it fails: After lvcreate -s creates the snapshot, it exists as a block device, but performing file-level operations directly on that raw device without mounting it is incorrect; tools like tar, rsync, or find expect a mounted filesystem path, not a device node. Without a mount, you cannot traverse the filesystem's directory structure, and any raw write to the device would bypass journaling/filesystem layers and risk corrupting the snapshot data. Therefore mount the snapshot to a directory before attempting operations such as backups.

Create snapshot using lvcreate -s, Mount snapshot to a directory, Remove snapshot, Perform operations on snapshot, Unmount snapshot

Why it fails: Removing the snapshot while it is still mounted fails in practice because lvremove detects the active logical volume and refuses to run while the device is in use, returning a volume is busy error. Placing Remove snapshot before Perform operations also contradicts the fact that operations require the snapshot to exist; once lvremove succeeds the snapshot device disappears, making later mounts or operations impossible. The only safe order is to mount, operate, unmount, and only then run lvremove to release the CoW space.

It treats unset variables as an error

Why it fails: The behavior described belongs to `set -u` (nounset), which causes the shell to abort when expanding an unset variable. `set -e` (errexit) only monitors the exit status of commands; it has no effect on variable expansion. An unset variable error is a different class of failure and is not triggered by `set -e`.

It prints each command before execution

Why it fails: Printing each command before execution is the job of `set -x` (xtrace), which expands commands and displays them on standard error with `PS4` as prefix. `set -e` does not generate any command tracing output; it changes the script's control flow by exiting on non-zero status. The xtrace option is for debugging, not for error handling.

It enables debug mode with verbose output

Why it fails: Debug mode with verbose output is enabled by `set -v` (verbose) which echoes input lines as read, or by `set -x` for executed commands. `set -e` is strictly an error-exit switch, not a debug facility. It does not produce diagnostic output; it only causes an immediate exit upon a failing command, which is unrelated to enabling tracing or verbose mode.

for i in $(seq 1 $(wc -l < hosts)); do ... done

Why it fails: Incorrect. This approach uses a for loop that generates a sequence of line numbers using seq and wc, then reads lines with sed. It is unnecessarily complex and fragile; any change in whitespace or special characters in hostnames can cause issues. Additionally, it spawns multiple subshells and is inefficient.

for host in $(cat hosts); do ... done

Why it fails: Incorrect. Using `for host in $(cat hosts); do ... done` subjects the content to word splitting and glob expansion. If a hostname contains spaces or wildcard characters, it will be split or expanded, leading to errors.

until read host; do ... done < hosts

Why it fails: Incorrect. The `until` loop is the inverse of `while`; it continues until the condition is true. The condition `read host` returns true as long as lines are read, so this loop would not execute at all because `until read host` fails immediately (read returns 0 when a line is read, so condition is false at start). Thus it never reads any lines.

dir=${@:-.}

Why it fails: The expression `${@:-.}` is conceptually flawed because `$@` represents all positional parameters as a list, not the first argument. The `:-` operator, when applied to `$@` in this form, does not isolate the initial directory name; instead, it expands to the entire argument list, or to `.` only if no arguments exist at all. This would assign the full list of arguments (or current directory) to `dir`, which breaks the intended single-directory semantics and can produce unexpected word-splitting or quoting behavior.

dir=${0:-.}

Why it fails: The use of `${0:-.}` is categorically wrong because `$0` is the name of the script itself, not the first positional argument. The `:-` operator is essentially a no-op here because `$0` is virtually always set by the shell when the script runs; even if it were unset, the expansion would substitute `.` only in that extremely unlikely scenario, leaving `dir` set to the script's filename, which is not a directory path and cannot satisfy the requirement.

dir=${?:-.}

Why it fails: The expansion `${?:-.}` is invalid as a directory argument because `$?` holds the exit status of the most recently executed foreground pipeline, not an argument or path. The `:-` combination produces a value like `.-` when the status is non-null (which it always is after any command), or `.` if the status is null, but neither result is a directory path. Using `$?` here is a misinterpretation of shell parameters, as the special variable `$?` has no connection to command-line arguments.

Use 'df -h / | tail -1 | sed 's/.* //' | tr -d '%'

Why it fails: Fragile because it parses the human-readable output from 'df -h' with sed. The formatting of 'df -h' can vary across systems; for example, the percentage field may not be the last field, or there may be multiple spaces, making 's/.* //' unreliable. Additionally, using 'tail -1' assumes the output has only two lines, which may not hold if there are multiple mount points in /? This approach is not portable.

Use 'df -h / | tail -1 | cut -d' ' -f5'

Why it fails: This option also uses `-h` and attempts to use `cut` with space delimiter. However, `df -h` output may have multiple spaces or different column ordering, so `cut -d' ' -f5` may not always extract the correct field. This is unreliable for portability.

Use 'df -h / | grep -oP '\d+%'

Why it fails: This option uses `df -h` and `grep` with a Perl regex to extract digits followed by '%'. While it may work on some systems, the human-readable output can vary, and the regex might not match all cases (e.g., if the percentage is like '100%' or has a leading space). It is less reliable than the approach in C.

set -e; ./risky_command; rc=$?; echo $rc

Why it fails: The errexit option (set -e) causes the shell to terminate immediately when risky_command returns a non-zero exit status, so the subsequent rc=$? line is never executed. This means a failing command aborts the entire script before the exit code can be captured, making the echo statement unreachable. Only if the command succeeds would flow continue, but then rc would be 0 and the failure case is lost.

rc=$? ./risky_command; echo $rc

Why it fails: This syntax performs the variable assignment rc=$? before risky_command is invoked, so it captures the exit status of the previous command, not risky_command. Moreover, because the assignment precedes a command, it is scoped to that command's environment only; the variable is not updated in the current shell session when the command exits. Consequently, echo $rc prints the old status, which is unrelated to risky_command.

./risky_command && rc=$?; echo $rc

Why it fails: The && operator is a logical AND that runs the right-hand command only if the left-hand command exits with status 0. If risky_command fails with a non-zero status, rc=$? is skipped, leaving rc unset or containing a stale value from a previous statement. The final echo $rc then outputs either a blank line (if unset) or the wrong exit code, so this pattern does not reliably capture failure status.