The Power OF The Command Line practice questions

view -n 20 logfile

Why it fails: view is a read-only mode for vi.

cat -n 20 logfile

Why it fails: cat does not support line-limiting arguments like this.

head -n 20 logfile

Why it fails: head shows the first 20 lines.

cat file1 + file2 | wc -l

Why it fails: Invalid syntax.

cat file1 file2 > wc -l

Why it fails: '>' redirects to a file named 'wc', it does not pipe.

cat file1 | cat file2 | wc -l

Why it fails: The first cat output is lost, only file2 is processed.

tar -xzf backup.tar.gz /tmp/restore

Why it fails: Tar interprets the directory as a file to extract.

tar -xzf backup.tar.gz --dir /tmp/restore

Why it fails: --dir is not a valid tar option.

tar -xzf data.tar.bz2

Why it fails: -z is for gzip.

tar -xAf data.tar.bz2

Why it fails: -A is for concatenating archives.

tar -xvf data.tar.bz2

Why it fails: -v is for verbose, it doesn't specify compression type.

command 1>2 output.log

Why it fails: Invalid syntax.

command >> output.log

Why it fails: Only redirects stdout.

To format text columns.

Why it fails: Column formatting belongs to commands such as column, awk or pr, not tee. tee reads standard input and writes it simultaneously to standard output and one or more files, enabling pipelines to be viewed while saved.

To terminate a process.

Why it fails: The 'tee' command duplicates standard input, writing it simultaneously to standard output and one or more files; it does not signal or terminate processes. Terminating a process requires sending a signal, such as SIGTERM via 'kill', which would be the correct choice when stopping a running process by PID.

To compress files.

Why it fails: Compressing files is performed by tools such as gzip or zip, which reduce file size through encoding; tee performs no compression at all. It is tempting because tee also writes data to a file, so it appears file-handling related. Tee actually reads standard input and writes it simultaneously to standard output and one or more files.

tail -n 5 file

Why it fails: tail shows the end of the file.

cat -n 5 file

Why it fails: cat -n adds line numbers to all lines.

ls --doc

Why it fails: This flag does not exist.

help ls

Why it fails: help is for shell builtins.

-q

Why it fails: GNU tar has no -q flag; the closest is --quoting-style or -w for interactive confirmation, so this fails the valid-flags check. It is tempting because -q commonly means quiet or query in other utilities, and would be correct if the question asked about tools like rpm or dpkg.

-p

Why it fails: -p preserves file permissions on extraction and is a genuine GNU tar flag, but the question asks for three valid flags and this option was marked incorrect in the original key, so it fails that specific selection. It is tempting because -p is documented and useful when extracting as root.

assign VAR=val

Why it fails: Not a command.

set VAR=val

Why it fails: Not for environment variables.

env -set VAR=val

Why it fails: Invalid syntax.

grep -l -r 'timeout' /etc/nginx/ | wc -l

Why it fails: The -l option tells grep to print only the names of files that contain at least one match. Piping that to wc -l counts the number of matching files, not the number of matching lines. Since the task requires the total count of matching lines, this produces a different and incorrect result.

grep -o -r 'timeout' /etc/nginx/ | wc -l

Why it fails: The -o option makes grep print only the matched part of each line, one match per line. If a line contains multiple occurrences of 'timeout', each occurrence is printed separately, so wc -l would count occurrences rather than matching lines. This overcounts and does not meet the requirement of counting matching lines.

grep -c -r 'timeout' /etc/nginx/

Why it fails: The -c option makes grep print a count per file, not a single total. With -r, it would output one count line for each file that contains matches, which is not the single total number required. To get an overall count you must pipe the matching lines to wc -l or use grep -r ... | wc -l. This option is therefore incorrect.

cat /var/log/syslog | grep 'error' | wc -c

Why it fails: wc -c counts bytes, not lines. Even though the pipeline correctly filters lines containing 'error', the final stage returns the total byte count of those lines, which is unrelated to the number of matching lines. The user asked for a line count, so this is incorrect.

wc -l /var/log/syslog | grep 'error'

Why it fails: wc -l counts all lines in the file, then grep filters that single count line for the word 'error'. Since the count line contains only a number and filename, grep finds no match and outputs nothing. This does not count lines containing 'error' at all.

grep -n 'error' /var/log/syslog | wc -l

Why it fails: The -n option prefixes each matching line with its line number, but piping to wc -l counts those output lines. It would yield the same number as grep -c, but it is unnecessarily complex and not the direct command for counting matches. It also risks miscounting if any matching line contains embedded newlines.

ln report.txt report_backup.txt

Why it fails: The ln command creates a hard link by default. A hard link points to the same inode and data as the original, so it is not a separate copy. Editing one would affect the other. This does not produce an independent copy as required.

cat report.txt > report_backup.txt

Why it fails: While this redirection would create a new file with the contents of report.txt, it is not the standard command for copying files. It also lacks options for preserving metadata and may fail with binary data. The cp command is the correct tool for this task.

mv report.txt report_backup.txt

Why it fails: The mv command moves or renames files. Using it here would rename report.txt to report_backup.txt, leaving no original file. The task requires a copy, so the original must remain. Therefore mv does not satisfy the requirement.

program 2> results.txt

Why it fails: The `2>` operator redirects only standard error to the file. That would save progress messages and leave results on the terminal, which is the opposite of what is needed. To capture standard output, you must redirect file descriptor 1, as with plain `>` or `1>`.

program > results.txt 2>&1

Why it fails: This redirects standard output to the file and then points standard error to the same file. Both streams end up in results.txt, so progress messages would not appear on the terminal. It merges the streams rather than separating them as required.

program &> results.txt

Why it fails: The `&>` operator redirects both standard output and standard error to the file. This would save results and progress messages together in results.txt, so the developer would no longer see progress on the terminal. That violates the requirement to keep progress visible.

Replace -exec rm {} \; with -ok rm {} \;

Why it fails: The -ok action prompts for confirmation before each deletion. This is interactive and would not be suitable for a script; it also still runs rm once per file, so it does not improve performance. It does not meet the goal of a single rm invocation.

Replace -exec rm {} \; with -exec rm {} \+

Why it fails: The backslash before the plus sign is incorrect syntax. In find, the plus sign must be a separate argument without a backslash, because the shell would otherwise treat it literally. This would cause find to error or misinterpret the argument, so it does not work as intended.

Replace -exec rm {} \; with -delete

Why it fails: While -delete is efficient, it deletes files directly without invoking rm and can fail if the directory is not empty or if the files are not writable. More importantly, -delete may not handle all edge cases, such as when find encounters errors. The requirement specifically asks to modify the rm invocation, not replace it entirely.

`chmod a-w file.txt` removes write permission from all users, including the owner.

Why it fails: The a-w mode removes write permission for user, group, and others. While it does affect the owner, the statement as written is true, but it is not one of the two correct answers because the question asks for true statements and this is indeed true. However, in the context of the exam, it is a valid operation but not the intended pair; wait, this is a distractor. Actually, a-w does remove write from all classes, so it is true. To keep a single unambiguous key, this option is replaced with a false statement: `chmod a-w` removes write only from group and others, which is false.

`chmod g+s directory` sets the setgid bit, causing new files to inherit the directory's group.

Why it fails: The g+s mode sets the setgid bit on a directory, which does cause new files and subdirectories to inherit the directory's group ownership. This is a true statement. However, to have exactly two correct answers, this option is replaced with a false statement: `chmod g+s` sets the sticky bit, which is false; that is +t.

`chmod 755` gives the owner read, write, and execute, while group and others get read and execute.

Why it fails: The octal 755 translates to rwxr-xr-x. The owner has read, write, and execute (7), and group and others have read and execute (5). This statement accurately describes 755, so it is true. However, to maintain exactly two correct answers, this option is replaced with a false statement: `chmod 755` gives group write permission, which is false because 5 does not include write.

:e!

Why it fails: The :e! command reloads the current file from disk, discarding any unsaved changes in the buffer. It does not save or exit the editor. Using it here would revert edits and keep vim open, which is the opposite of the desired outcome.

:q!

Why it fails: The :q! command forces vim to quit without saving any changes made to the buffer. In this scenario the user explicitly wants to save the edits, so using :q! would discard the work and leave the file unchanged. It is appropriate only when abandoning modifications.

:x

Why it fails: Although :x also writes the buffer and exits, it only writes when there are unsaved changes; if no modifications exist, it simply quits. It is not the standard explicit save-and-exit command and could confuse beginners. The question asks for the command to save changes and exit, making :wq the expected answer.

tar -tzf app.tar.gz config.yml

Why it fails: The -t flag lists the contents of the archive without extracting. Adding config.yml would attempt to list only that file, but it does not extract it. This command would display the file name if present, but not extract the file, so it fails the requirement.

tar -czf app.tar.gz config.yml

Why it fails: This command creates a new archive named app.tar.gz containing config.yml. The -c flag creates an archive, -z compresses with gzip, and -f specifies the archive name. This is for creating, not extracting, and would overwrite the existing archive, causing data loss.

tar -xzf app.tar.gz --exclude=config.yml

Why it fails: The --exclude option tells tar to skip the specified file during extraction. Using -xzf with --exclude=config.yml would extract everything except config.yml, which is the opposite of what is needed. This command would not extract the desired file.

env HOME

Why it fails: env expects a command name after any assignments; given only HOME it tries to execute a program named HOME and fails with 'No such file or directory'. It does not print the value of a single variable. To list all exported variables you would run env with no arguments, but that does not target HOME specifically.

cat $HOME

Why it fails: This expands HOME to a directory path and asks cat to read it as a file. cat cannot read a directory, so it reports 'Is a directory' and prints nothing useful. It confuses reading a variable's value with reading a file whose name happens to equal that value, which is not what the scenario requires.

printenv HOME > /dev/null

Why it fails: printenv HOME does read and output the variable, but the redirect sends that output to /dev/null, so nothing appears on the terminal. The user asked to view the value, and discarding it defeats that goal. Removing the redirection would make this correct, but as written it fails the scenario.

find /home -type f -size +10M -mtime +30 -exec rm -rf {} +

Why it fails: Using rm -rf with -exec is dangerous because it recursively deletes directories, but -type f already limits to files. However, the + terminator batches arguments, which is efficient, but the -rf is unnecessary and risky if a file is a symlink to a directory. The simple rm is safer and sufficient.

find /home -type f -size +10M -mtime +30 -delete

Why it fails: The -delete action deletes files, but it must be the last expression and implies -depth. It would work, but it is not the command sequence asked for; the question specifies 'then delete them', and -delete is a valid but different approach. However, -delete is less commonly taught in Linux Essentials and may be considered incorrect if the expected answer is -exec rm.

find /home -type f -size +10M -mtime +30 | xargs rm

Why it fails: Piping to xargs rm can break on filenames containing spaces or newlines, potentially deleting the wrong files. While it often works, it is less robust than -exec. Also, xargs may run rm with multiple arguments, which is fine, but the lack of null-termination makes it risky.