Shells, Scripting and Data Management practice questions

The cron job lacks the PATH environment variable.

Why it fails: The cron job specifies the full path to the script.

The script is owned by root, but the cron job runs as a different user.

Why it fails: Cron runs as root, matching the owner.

The script lacks a shebang line.

Why it fails: A shebang is not required for cron if the script is executable.

ps -ef | sort -k5,5 -rn

Why it fails: Incorrect. `ps -ef` does not show RSS; the 5th field is STIME, not RSS.

ps -ef | sort -k3 -rn

Why it fails: Incorrect. The 3rd field in `ps -ef` is PPID, not RSS.

ps --sort=rss

Why it fails: Incorrect. `--sort=rss` sorts by RSS in ascending order, not descending.

ps -ef | sort -k5 -rn

Why it fails: Incorrect. `ps -ef` does not include RSS; the 5th field is STIME.

The cron daemon is not running.

Why it fails: A stopped cron daemon would prevent the job from running at all, contradicting the observation that it executes. The absence of output points instead to the script writing nothing to stdout or stderr, or cron mailing it. Daemon failure is the cause when jobs never fire.

The script requires a terminal to run.

Why it fails: Cron runs jobs detached from any controlling terminal, so scripts needing a TTY fail rather than run silently; the stem states the job runs. Missing output stems from the script producing none, or cron mailing it. Terminal dependence is the cause when jobs error under cron but succeed interactively.

Cron automatically suppresses all output.

Why it fails: Cron does not suppress output; it captures stdout and stderr and mails them to the job owner unless redirected. Silence therefore means the script emitted nothing, or mail is unread. Redirecting output to a log file is the deliberate choice when suppression is actually wanted.

The 'notifempty' directive is misspelled; it should be 'notifempty'.

Why it fails: Incorrect. 'notifempty' is the correct directive name; there is no misspelling. This directive prevents rotation if the log file is empty, but it is not the reason rotation fails.

The /etc/logrotate.d/ directory is not included by logrotate.conf.

Why it fails: Incorrect. /etc/logrotate.conf includes /etc/logrotate.d/*, so the configuration file is being processed.

The 'missingok' directive prevents rotation if the log file is missing, but the file exists.

Why it fails: 'missingok' only suppresses errors when the file is absent; it never blocks rotation of an existing file, so it cannot explain the failure. It is tempting because the directive concerns file presence, and it would be relevant only if the log were genuinely missing at rotation time.

cat data.txt | wc -c

Why it fails: wc -c counts characters.

grep -c '.*' data.txt

Why it fails: grep -c counts matching lines; '.*' matches all lines but if file empty, count is 0; not standard.

sed -n '$=' data.txt

Why it fails: sed -n '$=' prints line number of last line, not count (same if file non-empty but fails for empty).

The script interpreter specified in the shebang is missing.

Why it fails: A missing shebang interpreter yields exactly this misleading error, since bash reports the interpreter path, not the script. It is tempting because shebang faults are a common cause of scripts failing to launch, but the exhibit already confirms the file is a valid executable, so the interpreter itself is present.

The library libc.so.6 is missing.

Why it fails: A missing libc.so.6 would surface as a dynamic linker error naming the library, not bash's 'No such file or directory' for the binary path. It tempts because shared-library breakage genuinely stops executables launching, but that scenario produces a distinct loader message, not this one.

The file does not have execute permission for the user.

Why it fails: Without execute permission, bash reports 'Permission denied', not 'No such file or directory'. It is tempting because permission faults are the usual reason a valid executable will not run, but the stem already states the file is a valid executable, so this mechanism cannot produce the observed message.

Create the user account using useradd, add the user to the sudo group using usermod -aG sudo, then set the password using passwd

Why it fails: This is incorrect because while it is possible to add a user to a group without a password, it is conventional and more secure to set the password before granting sudo privileges to ensure the user can authenticate immediately. Also, some systems may require password to be set before first sudo attempt.

Set the password using passwd, create the user account using useradd, then add the user to the sudo group using usermod -aG sudo

Why it fails: This is incorrect because the user does not yet exist when trying to set the password (passwd requires an existing user). The user must be created first.

Set the password using passwd, add the user to the sudo group using usermod -aG sudo, then create the user account using useradd

Why it fails: This is incorrect because both setting the password and modifying group membership require an existing user. Creating the user last makes the first two steps fail.

The file has an empty line at the end.

Why it fails: Would not cause variable to be empty after loop.

The variable is declared as readonly.

Why it fails: Would cause an error, not just empty.

The variable name contains spaces.

Why it fails: Variable names cannot contain spaces.

<< EOF

Why it fails: Unquoted delimiter allows variable expansion.

<<- EOF

Why it fails: Allows leading tabs and variable expansion.

<< "EOF"

Why it fails: Double quotes still allow variable expansion.

cat file | uniq | sort

Why it fails: Incorrect. This pipeline applies `uniq` before `sort`, so only adjacent duplicates are removed. If the file is not already sorted, non-adjacent duplicates remain, and the final output may contain duplicates.

sort -u file

Why it fails: Incorrect. `sort -u` does produce a sorted unique list, but it is a single command, not a combination of multiple commands. The question asks for a 'command combination', implying a pipeline.

Both A and C

Why it fails: Does not always work, so stating that both A and C are correct is false.

echo ${/home/user/script.sh%/*}

Why it fails: Incorrect. The syntax `${/home/user/script.sh%/*}` is invalid; parameter expansion requires a variable name, not a literal string.

Either dirname or the expansion ${path%/*} if path is set to the full path

Why it fails: Incorrect. While both `dirname` and `${path%/*}` are valid methods, the question asks for a command; `dirname` is the command, but option C presents it as 'either', which does not answer the question directly.

basename /home/user/script.sh

Why it fails: Incorrect. `basename` returns the filename component (e.g., `script.sh`), not the directory.

The script must not contain any comments.

Why it fails: Comments are allowed.

The script must have a .sh extension.

Why it fails: Extension is not required.

The script must be in the PATH environment variable.

Why it fails: It can be run with ./ if not in PATH.

tr

Why it fails: Translates characters, not fields.

cat

Why it fails: Just outputs the file.

a b\nd e

Why it fails: Incorrect. This output would occur if `read` assigned only the first word to each variable and discarded the rest, but the last variable actually captures the remainder.

a b

Why it fails: Incorrect. This output would result if the script only printed the first variable from each line, ignoring the rest.

The script will error because of incorrect read syntax.

Why it fails: Incorrect. The syntax is valid; `read` does not error when there are more words than variables.

find /home/user/project -name '*.txt' -exec chgrp developers {} \;

Why it fails: This sets group ownership to 'developers' but leaves permissions unchanged, so the 640 requirement is unmet. It is tempting because chgrp correctly targets the group, yet the stem requires both ownership and mode changes in one command, which this omits.

chmod -R 640 /home/user/project/*.txt

Why it fails: chmod changes permission bits only; it never alters group ownership, so the required chgrp to 'developers' is missing. It is tempting because it sets the 640 mode, but the stem demands both ownership and permissions, which only a combined find with chgrp and chmod satisfies.

find /home/user/project -name '*.txt' -exec chmod 640 {} \;

Why it fails: This sets mode 640 but never changes group ownership to 'developers', leaving the chgrp requirement unmet. It is tempting because chmod applies the correct permissions, yet the stem demands both ownership and mode changes, which this command alone does not deliver.

awk '{print $1}' access.log | sort | uniq | sort -rn

Why it fails: uniq without -c only removes adjacent duplicates, so sort -rn then sorts the IP strings numerically, not by count; frequency is never computed. It is tempting because it chains familiar tools, and would be correct if the goal were merely unique addresses in reverse numeric order.

awk '{print $1}' access.log | sort -rn | uniq -c

Why it fails: sort -rn runs before uniq -c, so identical addresses are not yet adjacent and uniq counts each run separately, producing fragmented counts. It is tempting because reverse-numeric sorting appears to address frequency, and would be correct if input were already grouped by address.

awk '{print $1}' access.log | sort | uniq -c | sort -k2

Why it fails: uniq -c correctly counts occurrences, but sort -k2 sorts by the IP address field rather than the count, so output is alphabetical by address, not most frequent first. It is tempting because it does produce counts, and would be correct if ordering by address were required.

export ll='ls -la'

Why it fails: Export is for environment variables, not aliases; does not work.

echo "alias ll='ls -la'" >> ~/.bashrc

Why it fails: Appends the alias to ~/.bashrc but does not activate it in the current session.

alias ll='ls -la'

Why it fails: Creates a temporary alias only for the current shell session.

trap cleanup TERM

Why it fails: Missing quotes; cleanup may be interpreted as variable expansion.

trap 'cleanup' EXIT

Why it fails: Runs cleanup on any exit, not specifically SIGTERM.

trap "cleanup" 9

Why it fails: Signal 9 is SIGKILL, which cannot be caught or ignored.

-ctime 0

Why it fails: Matches based on change time (metadata), not modification time.

-newer file

Why it fails: Compares modification time to a reference file, not absolute time.

-atime 1

Why it fails: Matches based on access time, not modification time.

for file in *.txt; do ... done

Why it fails: Subject to word splitting; filenames with spaces would be split.

for file in $(find . -name '*.txt'); do ... done

Why it fails: Subject to word splitting and pathname expansion of the output.

for file in "*.txt"; do ... done

Why it fails: Treats the pattern as a literal string, not a glob.