CCNA Create simple shell scripts Questions

This is the exact purpose of `set -e`, also known as `errexit`. When enabled, the shell immediately exits if any simple command, pipeline, or compound command (outside of contexts like `if`, `while`, `until`, `!`, or `&&`/`||` left operands) returns a non-zero status. This halts the script at the first error rather than continuing with unchecked failures.

A script run via cron or an administrator's shell inherits a minimal PATH and can fail silently if critical commands like df or awk are missing or are non-executable. Including error handling, such as verifying prerequisites with command -v and checking the exit status of df, prevents the script from issuing false alerts or exiting with unrelated error codes. A graceful exit that logs a clear diagnostic message to stderr or syslog makes the failure self-evident and allows administrators to correct the environment rather than debug mysterious output.

The `bash -n script.sh` command invokes Bash's noexec mode, which causes the shell to read and parse the entire script but not execute any of its commands. The parser reports any syntax errors with the offending line number and returns a non-zero exit status, making this the standard method for syntax-checking a Bash script. Note that this check only validates grammar, not logical or runtime errors.

This option uses `df /` without `-h`, which produces a stable, machine-parseable output. The `awk` command extracts the fifth field (the percentage used) and `tr` removes the percent sign. This is portable across different Unix/Linux systems.

The command uses $home, which is a different variable name from $HOME because bash is case-sensitive. Environment variables like HOME are uppercase by convention, and the lowercase $home is not defined in any standard shell session, so it expands to an empty string. Assigning or exporting a lowercase home would require the script author to have previously set it, and echo "$home" would then output that value rather than the actual home directory. The only correct fix is to change the script to use $HOME (or ${HOME}).

The shell and many programs follow the convention that exit status 0 means successful completion, while any non-zero value signals an error, warning, or unusual termination. This convention is pervasive across UNIX-like systems and is relied upon by scripts, continuous integration pipelines, and command-line tools to make control-flow decisions. While specific programs may assign different meanings to specific non-zero codes, the general rule remains that non-zero means the command did not complete as intended.

Because only one argument is supplied, $# equals 1, the test [ $# -ne 2 ] is true, the usage message is echoed to standard output, and exit 1 terminates the script with status 1. This matches the intended argument-validation pattern.

This is the correct behavior. When the command substitution `$(ls /etc/*.conf)` is left unquoted, the shell splits the result using the characters in `IFS` (space, tab, and newline by default). A file named, for example, `app config.conf` becomes two loop tokens, `app` and `config.conf`, causing the loop body to run extra times with incorrect arguments. These partial names are unlikely to exist, so the script produces errors and fails to handle the actual .conf files that have spaces.

When you execute a script by name or with ./script, the kernel starts a new shell process (child) with its own copy of the parent's environment. The export builtin marks VARIABLE for inheritance by that child, but any assignments or exports made inside the script modify only the child's environment, which is discarded when the script exits. Therefore the exported variable never appears in the parent shell, even though it is available to programs launched within the script. This is the fundamental process isolation you are observing.

Quoting variable expansions such as "$var" or "${var}" prevents the shell from performing word splitting (splitting the value on characters in IFS, typically whitespace) and pathname expansion (globbing) on the resulting tokens. Without quotes, a variable containing spaces or glob characters like '*' can be broken into multiple arguments or expanded into filenames in unexpected ways. Consistent quoting ensures that the value of the variable is passed as a single argument, which is essential for correctly handling filenames, paths, or data with special characters.

`wc -l /etc/passwd` writes the line count followed by a space and the filename (e.g., `37 /etc/passwd`) to stdout. Command substitution captures that entire string into `lines`, so `echo $((lines + 1))` attempts to perform arithmetic on a value that is not a valid integer literal. Because the filename is embedded in the variable, the shell cannot evaluate the expression. This is the fundamental problem: `lines` is not a pure number.

This is the only option that explicitly handles the signal that is actually interrupting the script. The trap directive installs a handler for SIGINT, so when Ctrl-C is sent, the shell runs "rm -f $tempfile; exit" instead of simply dying. Because the trap is installed at the top level before the long task begins, it remains in effect throughout the task, and the explicit exit prevents the shell from continuing after the cleanup runs. This guarantees the temporary file is removed even on user interruption.

read is a shell builtin that reads a line from standard input and splits it into words using IFS, assigning them to the listed variable names; when no variable is supplied, it stores the entire line in REPLY. Because it runs in the current shell process rather than a child process, the assigned variables remain available afterward, which is exactly what an interactive prompt requires. Its exit status reflects whether a line was actually read, so it also works in while loops.

Unquoted variable expansions are subject to word splitting and pathname expansion, so a filename like 'My File.txt' would be split into two arguments, and a value containing '*' could expand to multiple files. Quoting, as in "$file", preserves the variable's value as one literal argument, preventing these transformations. This is essential when handling user input, file paths, or any value with whitespace or glob characters.

The parameter expansion `${1:-.}` explicitly targets the first positional parameter (`$1`) and applies the `:-` operator: if `$1` is unset or null, the expansion substitutes the literal `.` (the current directory). This precisely fulfills the requirement to accept a directory argument with a sensible default when no argument is supplied, because `$1` is the first argument passed to the script, and the default value is only used when that argument is missing or empty.

Declaring variables with `local` inside a function constrains their scope to that function and its called subshells, preventing them from leaking into and clobbering global variables. This avoids hard-to-trace side effects, strengthens reusability and recursion, and is a core principle of writing clean, modular Bash functions.

The semicolon is a command terminator that allows rc=$? to execute regardless of how risky_command exited. After risky_command finishes, $? holds its exact exit status, and the assignment immediately stores it before any other command or expansion can alter it. The subsequent echo $rc then prints the saved value, making this the correct pattern for capturing a failure status without terminating the script.

The `while read host; do ... done < hosts` construct is the correct approach because it reads the file line by line. On each iteration, `read` assigns the entire line (minus trailing newline) to the variable `host`, so the content is not subjected to word splitting or pathname expansion. This makes it robust for hostnames that might contain unusual characters, though for exact preservation one should add `IFS=` and `-r` to `read`. Additionally, the redirection `< hosts` attaches the file to the loop's standard input, and the loop runs in the current shell, so any variable updates inside the loop remain available afterward.

The correct action is to grant execute permission explicitly. The chmod +x command adds the execute bit (x) to the file's mode for the user, group, and others, which is required for the kernel to allow execve to run the script directly. Without this bit, the shell returns 'Permission denied' even though the user can read and write the file. Since the devops user already owns the file and has read/write permissions, adding the execute bit is the minimal, sufficient fix to make the script runnable.

trap - SIGINT resets SIGINT to its default disposition, undoing the earlier ignore. The hyphen tells the shell to restore default handling rather than run a command, which is exactly the re-enable behaviour the script needs after ignoring Ctrl+C.

In the given script, if an intended command is followed by a [[ ... ]] test, $? will reflect the exit status of the [[ ]] evaluation, not the earlier command. For example, if the script does [[ -f file ]] after running an application, $? becomes 1 when file does not exist, even if the application succeeded. Because $? is overwritten by each subsequent command, any intervening conditional destroys the original exit value.

Setting IFS= ensures read does not trim leading or trailing whitespace from each line, preserving the exact content of the input. The -r flag prevents backslashes from being interpreted as escape characters, so paths like C:\new remain literal. Quoting "$line" in the echo command prevents word splitting and glob expansion, and < file.txt correctly redirects the file to the loop's stdin line by line. This combination is the canonical robust way to process lines in Bash.

In a non-interactive shell, an unmatched glob like /var/log/myapp/*.log is not expanded and is passed literally to cp. cp then attempts to copy a file named `*.log`, which does not exist, producing a 'No such file or directory' error and creating no backup. Unless the script checks the glob result or has error handling, this failure can be silent, especially if cron's stderr output is not inspected.

The shebang line is a special two-byte sequence (0x23 0x21) followed by an absolute path to an interpreter, such as #!/bin/bash. When the kernel tries to execute a script directly, it reads the first line, sees the shebang, and launches the specified interpreter with the script as its argument. If the interpreter path is invalid, the script fails with a "bad interpreter" error, so the shebang is essential for scripts executed as standalone commands. However, a script can omit the shebang if it is explicitly run as the argument to an interpreter, e.g., bash script.sh.

The shell expands `*.txt` to the names of matching files in the current directory, which in the given directory listing are `a.txt` and `b.txt`. The `for i in` loop assigns each name in turn to `i`, and `wc -l "$i"` prints the line count for each file. Files in subdirectories such as `backup` are not matched because globbing is not recursive unless `**` is used.

This answer correctly re-establishes trust by fetching the remote server's current public host keys with ssh-keyscan and appending them to the management server's known_hosts file. After this update, scp will find the new host key for that server and pass verification, allowing the cron job to run normally. To preserve security, the administrator should verify the retrieved fingerprints out-of-band (for example, by comparing the server's SSH host key fingerprint from the console) before adding them, because blindly accepting keys could still allow man-in-the-middle attacks.

The variable $var is empty or unset, and because it is referenced without double quotes, the shell expands it to an empty string and then removes it entirely during word splitting. That causes [ $var = value ] to become [ = value ], which the test command sees as two arguments; it tries to treat '=' as a unary operator, producing the 'unary operator expected' error. Properly quoting as [ "$var" = value ] would keep the empty argument and yield a valid comparison, confirming the diagnosis.