Question 1

On Unix/Linux, which command is commonly used both to display file contents and, via redirection, to create simple files?

Accepted Answer

Introduction / Context: Unix utilities excel by doing one thing well and composing with redirection and pipelines. The classic tool for displaying file contents is also frequently used to create simple files by redirecting its output. Recognizing this pattern helps with quick notes, logs, and test data without invoking a full-screen editor. Given Data / Assumptions: We seek a command that can display file contents to standard output. We also want to be able to create files using shell redirection. Minimalism is preferred over full-screen editing. Concept / Approach: cat (concatenate) prints files to standard output. Combined with redirection, it can create files: for example, cat > notes.txt then typing lines and pressing CTRL+D saves the content. It can also join multiple files: cat a.txt b.txt > both.txt. Editors like vi and ed can create files too, but the question emphasizes a command used to display and—via shell features—create files quickly. Step-by-Step Solution: To display: cat file.txtTo create: cat > new.txt (type content, CTRL+D to end)To append: cat >> existing.txtTo concatenate: cat file1 file2 > merged.txt Verification / Alternative check: After creation, confirm with ls -l new.txt and cat new.txt to view the contents. This demonstrates both display and create behaviors in practice. Why Other Options Are Wrong: vi, ed: editors; they are used primarily for interactive editing, not simply displaying output to stdout by default. lyrix: not a standard Unix command. None of the above: incorrect because cat satisfies both uses. Common Pitfalls: Accidentally truncating files with >; use >> to append. Using cat for large binaries to the terminal can corrupt display; redirect or use od/hexdump. Final Answer: cat.

Question 2

Which ls invocation shows the attributes of a directory entry itself (permissions, owner, size, timestamp) rather than listing its contents?

Accepted Answer

Introduction / Context: Sometimes you need metadata about a directory (its mode bits, owner, size on disk, and timestamps) instead of the names it contains. The ls command provides a way to list the directory entry itself, which is essential for permission troubleshooting and scripting around directory attributes. Given Data / Assumptions: You want details of a directory as an object, not the directory's contents. You are using ls with familiar flags. Standard GNU/BSD ls semantics apply. Concept / Approach: The -d option tells ls to list directories themselves, not their contents. Combining with -l (long format) shows permissions, ownership, size, and timestamp. For example, ls -ld /var/log outputs the metadata for /var/log as a single line, rather than enumerating files within it. Step-by-Step Solution: Choose -d to avoid descending into directories.Add -l to display detailed attributes.Command: ls -l -d DIRNAME (or ls -ld DIRNAME)Interpret output fields (mode, links, owner, group, size, date, name). Verification / Alternative check: Compare ls -l /tmp (lists contents) versus ls -ld /tmp (shows directory entry). The latter confirms the correct behavior. Why Other Options Are Wrong: ls -l: lists directory contents in long format. ls -x: fills rows across; does not target directory entry. ls -F: appends indicators (/ for directories); does not change listing target. None of the above: incorrect because ls -l -d is correct. Common Pitfalls: Forgetting -d and getting a long list of contained files instead of the directory's metadata. Confusing directory permissions (execute on directory allows traversal, not execution of files). Final Answer: ls -l -d.

Question 3

In Unix/Linux file management, which command is used to remove (delete) a file from the filesystem?

Accepted Answer

Introduction / Context: Deleting files is a frequent administrative and user task. Unix/Linux provides a simple command specifically for removing files and, with the right options, directories. Knowing the correct command—and its safety flags—prevents accidental data loss and improves scripting reliability. Given Data / Assumptions: You need to delete regular files from the command line. Standard POSIX commands are available. Basic usage suffices; recursive deletion is a related but separate option. Concept / Approach: The command to remove files is rm. By default it unlinks each file name. To remove directories and their contents, use rm -r (or -rf with caution). Other listed commands are either nonstandard or have different semantics: mv moves/renames files; del is a DOS command; remove is not a standard Unix command-line tool. Step-by-Step Solution: Delete a file: rm file.txtDelete multiple: rm file1 file2Delete by glob: rm *.log (use with care)Delete directories: rm -r dir/ Verification / Alternative check: Run ls before and after rm to confirm removal. Use -i for interactive confirmation if safety is a concern. Why Other Options Are Wrong: remove: not a standard POSIX command. mv: moves/renames; doesn't delete. del: DOS/Windows command, not Unix. None of the above: incorrect because rm is correct. Common Pitfalls: Using rm -rf / or similar destructive globs; always double-check paths. Deleting files without permissions—prepend sudo if appropriate. Final Answer: rm.

Question 4

In the classic Unix 'mail' command interface, which single-letter command saves the current message into a separate file (mailbox or named file)?

Accepted Answer

Introduction / Context: Traditional Unix mail programs provide single-letter commands to manage messages from within the interactive prompt. Knowing how to save a message to a separate mailbox or file is essential for archiving, forwarding through scripts, and organizing important correspondence from the terminal. Given Data / Assumptions: Using the classic mail (or mailx) command-line interface. You have a message selected (by default the current one). You want to save it to a specified filename or mailbox. Concept / Approach: The s command (save) writes the current message to a named file or mailbox, including headers. Syntax typically is s filename. The similar command w (write) often writes the message body only (omitting some headers) depending on implementation, while d deletes, and r replies. Step-by-Step Solution: Open mail interface: mailSelect/read a message: type its number or press Enter for current.Save it: s saved.txt (or s +folder for mailbox)Quit: q (messages marked for deletion are removed) Verification / Alternative check: After saving, check the target file with ls -l saved.txt and view its contents using less saved.txt. You should see the message with headers intact. Why Other Options Are Wrong: r: reply to sender; does not save. w: writes the message (often body only); the question emphasizes saving to a separate file in standard practice, which is s. d: delete message. None of the above: incorrect because s is the conventional save command. Common Pitfalls: Confusing s and w differences across variants (mail vs mailx vs Heirloom); when in doubt, check man mail. Forgetting to specify a filename causes save to default mailbox behavior. Final Answer: s.

Question 5

From a Unix/Linux perspective, does the cp (copy) command use standard input or standard output streams during normal file-to-file copying?

Accepted Answer

Introduction / Context: Understanding how core utilities interact with Unix streams clarifies when to use redirection and when to let tools operate directly on files. While many commands read from stdin and write to stdout by default, some file utilities open source and destination paths themselves without involving the shell's standard streams. Given Data / Assumptions: We are discussing normal cp SRC DEST usage. No pipelines or redirections are used with cp. Filesystem permissions allow reading SRC and writing DEST. Concept / Approach: cp opens the source path directly for reading and the destination path for writing using system calls (e.g., open/read/write). It does not read from standard input nor write to standard output during routine copying; instead, it operates on file descriptors associated with the named files. This differs from tools like cat or sed, which naturally connect to stdin/stdout in pipelines. Step-by-Step Solution: Identify default behavior: cp SRC DEST.Recognize that cp handles files directly, not streams.Confirm no stdin/stdout involvement in ordinary operation.Conclude answer: neither stdin nor stdout. Verification / Alternative check: Strace or audit cp: you will see open() on SRC and DEST rather than reads on file descriptor 0 (stdin) or writes on descriptor 1 (stdout). This confirms stream independence for standard usage. Why Other Options Are Wrong: standard input file / standard output file / both: do not reflect cp's normal file-to-file operation. None of the above: incorrect because “neither stdin nor stdout” is correct. Common Pitfalls: Assuming all commands are stream-based; many file utilities work directly on paths. Using cp -i for safety to avoid overwrites; this still does not use stdout. Final Answer: neither standard input nor standard output file.

Question 6

Which of the following is not considered a user-to-user communication command in Unix/Linux environments?

Accepted Answer

Introduction / Context: Unix provides several utilities for interactive communication between users on the same system or across systems. Distinguishing these from text-processing tools is important when administering multi-user environments or studying classic Unix command sets. Given Data / Assumptions: The commands listed are common on traditional Unix systems. We are identifying which one is not meant for user communication. Basic behaviors of each command are assumed knowledge. Concept / Approach: write sends a message to another logged-in user's terminal. mesg controls whether a terminal will accept messages from others (e.g., mesg n to disallow). mail (or mailx) handles sending and reading electronic mail. In contrast, grep is a pattern-matching utility for searching text streams; it does not provide user-to-user communication. Step-by-Step Solution: List communication tools: write, mesg, mail.Identify the outlier: grep is text search.Confirm by usage examples.Select the non-communication command. Verification / Alternative check: Try write user (if enabled) to send a message; use mesg to toggle; mail user to send email. grep searches text, e.g., grep ERROR /var/log/syslog, confirming its different role. Why Other Options Are Wrong: write: direct terminal-to-terminal messaging. mesg: controls message permission; part of communication workflow. mail: email utility; explicit communication. None of the above: incorrect; one item (grep) is clearly not a communication command. Common Pitfalls: Assuming mesg sends messages; it only enables/disables reception. Confusing mail (local MTA interface) with modern MUAs; the principle remains the same. Final Answer: grep.

Question 7

In Unix/Linux system administration, which command is used to display the characteristics and current status of running processes (for example, PID, TTY, time, and command)?

Accepted Answer

Introduction / Context: Monitoring processes is a core Unix/Linux skill. Administrators and developers routinely need to list active processes, see their process IDs (PIDs), controlling terminals, CPU time usage, and the commands that launched them. The standard utility that reveals these characteristics in a flexible way is essential for troubleshooting performance, runaway tasks, and job control. Given Data / Assumptions: You are working on a Unix-like shell (bash/zsh). You want a snapshot of process attributes such as PID, TTY, CPU time, state, and command. No special kernel modules or third-party tools are assumed. Concept / Approach: The 'ps' command (process status) reports properties of processes. Common flags include 'ps aux' (BSD style) to view all processes with users, or 'ps -ef' (SysV style) for a full listing. You can filter by PID, user, or terminal, and format columns with '-o' for custom output. This makes 'ps' the go-to tool for a quick, scriptable view of process characteristics. Step-by-Step Solution: Run basic listing on your terminal: psShow every process on the system: ps auxFull-format SysV listing: ps -efCustom columns (PID and command): ps -eo pid,cmd Verification / Alternative check: Correlate the reported PID with '/proc/' entries (on Linux) or use 'top'/'htop' to see the same processes dynamically. The results should match, confirming 'ps' accurately surfaces process characteristics. Why Other Options Are Wrong: pid: Not a standard command; PID is a process attribute, not a listing tool. du: Reports disk usage, not processes. au: Not a standard process display utility. None of the above: Incorrect because 'ps' is correct. Common Pitfalls: Misinterpreting BSD vs SysV flags, forgetting to use root privileges for full listings, or assuming 'ps' is live-updating (it is a snapshot; use 'top' for continuous updates). Final Answer: ps

Question 8

In the vi editor on Unix/Linux, which command inserts text immediately to the left of the current cursor position (that is, before the cursor)?

Accepted Answer

Introduction / Context: The vi editor (and Vim) provides several concise insert commands for fast text editing. Knowing exactly where text will be inserted relative to the cursor prevents off-by-one mistakes and accelerates editing tasks in code, configuration files, and logs. Given Data / Assumptions: You are in Normal mode (press Esc to ensure). You want to insert text before the character under the cursor. Standard vi keybindings are active. Concept / Approach: The 'i' command enters Insert mode and places the insertion point immediately before the current cursor position. Other insert-like commands exist: 'a' appends after the cursor, 's' replaces the single character under the cursor and then inserts, and 'S' replaces the entire line. Choosing the correct command ensures the text lands exactly where intended. Step-by-Step Solution: Press Esc to return to Normal mode.Position the cursor on the target character.Press i to enter Insert mode.Type the new text, then press Esc to leave Insert mode. Verification / Alternative check: Compare behavior of 'i' vs 'a': 'i' inserts before the cursor; 'a' appends after. Use 'h' and 'l' to move left/right one character to confirm relative placement. Why Other Options Are Wrong: a: Inserts after the cursor (append), not before. s: Deletes the current character and then inserts. S: Deletes the entire line and then inserts at line start. None of the above: Incorrect because 'i' is correct. Common Pitfalls: Remaining in Insert mode inadvertently, confusing 'i' and 'a', or expecting visual block behavior without using the proper visual modes. Final Answer: i

Question 9

On Unix/Linux, which command makes all files and subdirectories within the directory named 'progs' executable by all users (recursively)?

Accepted Answer

Introduction / Context: Permissions control who can read, write, and execute files. When distributing scripts or binaries within a directory tree, administrators often need to grant execute permission broadly so that users can run these files without permission errors. A recursive and user-agnostic approach is typically used. Given Data / Assumptions: Target directory is 'progs' with nested content. You want execute permission for user, group, and others. You want to apply permissions recursively. Concept / Approach: 'chmod -R a+x progs' applies the execute bit for all classes (a = u,g,o) on every file and subdirectory under 'progs'. This grants traversal on directories and execution on executable files and scripts. It does not remove other permissions; it only adds +x. Alternatives shown are either invalid or set inappropriate modes. Step-by-Step Solution: Inspect current permissions: ls -lR progsGrant execute recursively: chmod -R a+x progsVerify changes: find progs -maxdepth 1 -exec ls -ld {{}} \;Adjust more granularly if needed (for example, only on files): find progs -type f -exec chmod a+x {{}} \; Verification / Alternative check: Run a representative script or binary to confirm it executes for non-owner accounts. Check directory traversal by ensuring 'x' is set on directories users must enter. Why Other Options Are Wrong: chmod -R 222 progs: Sets write-only bits, removing execute; unusable. chmod -1 a+x progs: Invalid syntax; '-1' is not a valid option. chmod -x a+x progs: Conflicting and nonsensical combined flags. None of the above: Incorrect because the first option is right. Common Pitfalls: Blindly setting execute on non-executable documents, or forgetting that directories require 'x' for traversal while files require 'x' for execution. Final Answer: chmod -R a+x progs

Question 10

On a Unix-like terminal, if you want to use Control-C as the interrupt key instead of Delete, which stty command correctly sets the interrupt character?

Accepted Answer

Introduction / Context: The terminal driver maps certain key combinations to control signals such as interrupt (INTR), quit, and erase. Customizing these mappings with 'stty' is useful on atypical keyboards or when your environment defaults differ. Here, we want Control-C to serve as the interrupt key that sends SIGINT to foreground processes. Given Data / Assumptions: You have a POSIX shell and the 'stty' utility available. Goal: set the interrupt character to Control-C. Shell may interpret carets, so escaping may be necessary. Concept / Approach: Use 'stty intr ^c' to set the INTR character. In many shells, the caret sequence is interpreted by 'stty' itself, but to avoid shell expansion issues, it is common to escape the caret as '\^c'. This ensures the literal control notation is passed correctly. After this change, pressing Control-C sends SIGINT to the foreground job as expected. Step-by-Step Solution: Check current settings: stty -a | grep intrSet interrupt to Ctrl-C: stty intr \^cTest: run a long command and press Ctrl-C to interrupt.Persist setting by adding the command to your shell startup file if desired. Verification / Alternative check: Run 'stty -a' again to see 'intr = ^C' reported. Start 'sleep 100' and press Ctrl-C; it should terminate with SIGINT. Why Other Options Are Wrong: tty ^c: 'tty' prints terminal name; it does not set control chars. stty echoe / stty echo \^a: These adjust echo behavior or unrelated settings; they do not set INTR to Ctrl-C. None of the above: Incorrect because 'stty intr \^c' is correct and safe. Common Pitfalls: Forgetting to escape special characters in some shells, or confusing 'erase' with 'intr'. Also note that some environments already default to ^C for interrupt. Final Answer: stty intr \^c

Question 11

In the vi editor, which single-key motion command moves the cursor forward to the next paragraph boundary (that is, to the end of the current paragraph / start of the next)?

Accepted Answer

Introduction / Context: Efficient navigation in vi relies on motion commands for words, sentences, and paragraphs. Paragraph motions are especially useful when editing prose, documentation, or code comments separated by blank lines or section macros. Given Data / Assumptions: Paragraphs are delimited by blank lines or defined macros (per vi settings). You want to move from within a paragraph to its boundary efficiently. Standard vi keybindings are assumed. Concept / Approach: In vi, '}' advances the cursor to the next paragraph boundary, effectively moving you past the end of the current paragraph and onto the first non-blank line of the next block. The inverse motion '{' moves to the previous paragraph boundary. Other motions like '$' and '|' operate within the current line only and do not consider paragraph structures. Step-by-Step Solution: Place the cursor anywhere in a paragraph.Press } to jump to the next paragraph boundary.Use { to move backward to the previous paragraph boundary.Combine with operators (for example, d}) to act on text until the next boundary. Verification / Alternative check: Test in a file with multiple blank-line-separated paragraphs. Press } repeatedly to step through paragraphs. Confirm that '$' only moves to end-of-line and does not change paragraphs. Why Other Options Are Wrong: {: Moves to the previous paragraph, not forward. $: Moves to the end of the current line only. |: Moves to a given column on the current line. None of the above: Incorrect because '}' is correct. Common Pitfalls: Misconfigured paragraph macros or unusual file formatting may alter boundary detection; ensure blank lines or proper macros exist for predictable movement. Final Answer: }

Question 12

In Unix/Linux process control, which command is commonly used to terminate a running process by sending a signal (for example, SIGTERM or SIGKILL)?

Accepted Answer

Introduction / Context: When a program hangs or must be stopped, Unix/Linux provides a signal mechanism to request termination. The standard user-space tool to send signals to processes—whether gentle or forceful—is fundamental for administration and scripting. Given Data / Assumptions: You know the process ID (PID) or can find it with 'ps'/'pgrep'. You want to end the process cleanly if possible. You have appropriate permissions to signal the process. Concept / Approach: Use 'kill PID' to send SIGTERM (15) by default, allowing the process to exit gracefully. If it does not respond, 'kill -9 PID' sends SIGKILL, which the process cannot catch or ignore. Other signals like SIGHUP can request reloads. The 'kill' command is versatile and supports multiple PIDs and process group signaling. Step-by-Step Solution: Identify the PID: ps -ef | grep appname or pgrep appnameTry graceful stop: kill Escalate if needed: kill -9 Verify: ps or pgrep again to ensure the process is gone. Verification / Alternative check: Check logs or process status post-signal. For services managed by init/systemd, use service-aware tools (for example, 'systemctl stop') which may call 'kill' under the hood. Why Other Options Are Wrong: shutdown / haltsys: System-level power management, not per-process termination. cancel: Not a standard Unix signal-sending command. None of the above: Incorrect because 'kill' is correct. Common Pitfalls: Overusing '-9' which bypasses cleanup, signaling the wrong PID, or failing to consider service managers that auto-respawn processes. Final Answer: kill

Question 13

In Unix/Linux filesystem management, which command removes a directory (typically only if it is empty)?

Accepted Answer

Introduction / Context: Deleting directories is a routine task. Unix/Linux distinguishes between removing empty directories safely and recursively deleting directory trees. Knowing the correct command for empty directories prevents accidental data loss and aligns with least-destructive defaults. Given Data / Assumptions: You want to remove a directory that contains no files or subdirectories. You prefer a command that fails safely if the directory is not empty. No nonstandard aliases are assumed. Concept / Approach: Use 'rmdir dir_name' to remove an empty directory. If the directory is not empty, 'rmdir' will refuse and report an error, prompting you to verify contents with 'ls -A'. For removing non-empty directories, the more dangerous 'rm -r dir_name' is required, often paired with '-i' for safety or used cautiously. Step-by-Step Solution: Check contents: ls -A target_dirIf empty, remove: rmdir target_dirIf not empty, consider: rm -r target_dir (with care)Confirm with ls that the directory is gone. Verification / Alternative check: Attempting 'rmdir' on a directory with files should fail, protecting you from accidental recursive deletions. Use 'find target_dir -maxdepth 1 -type f' to verify emptiness before removal. Why Other Options Are Wrong: rd / dldir / rdir: Not standard Unix/Linux commands ('rd' is DOS/Windows). None of the above: Incorrect because 'rmdir' is correct. Common Pitfalls: Confusing 'rmdir' with 'rm -r', forgetting hidden files may prevent 'rmdir', and lacking permissions to remove the directory. Final Answer: rmdir

Question 14

Which Unix/Linux command sorts the lines of a file in reverse (descending) order directly from the command line?

Accepted Answer

Introduction / Context: Sorting text data is fundamental in log analysis, report generation, and data cleaning. The standard 'sort' utility can order lines lexicographically or numerically, and supports reversing the order with a simple switch for quick, scriptable transformations. Given Data / Assumptions: You have a text file whose lines need reverse ordering. Default collation is acceptable (or you will add keys/switches). You want a one-liner solution. Concept / Approach: 'sort -r file' outputs the same lines in descending order. Combine with '-n' for numeric reverse order ('sort -nr'), or specify keys with '-k' for column-based sorts. Piping from another command is common in Unix pipelines to reverse-stream data on the fly. Step-by-Step Solution: Reverse lexicographic: sort -r data.txtReverse numeric by column 3: sort -k3,3nr data.txtReverse stdin: cmd | sort -rWrite to file: sort -r data.txt > reversed.txt Verification / Alternative check: Compare 'sort file' vs 'sort -r file' outputs to confirm reversed ordering. For numbers, add '-n' and verify correct numeric treatment rather than string ordering. Why Other Options Are Wrong: sort: Sorts ascending by default, not reverse. sh / st: Not sorting commands. None of the above: Incorrect because 'sort -r' is correct. Common Pitfalls: Forgetting '-n' for numeric data, locale-collation surprises, or neglecting '-k' when sorting on specific fields. Final Answer: sort -r

Question 15

On a Unix/Linux shell, which single character is used to separate multiple commands on the same command line so they run sequentially?

Accepted Answer

Introduction / Context: Command chaining improves productivity by letting you run several commands in order without new prompts. Understanding the correct separator character avoids syntax errors and ensures the shell executes each command sequentially regardless of prior exit codes (unless you use conditional operators like && or ||). Given Data / Assumptions: You are using a POSIX shell (bash, dash, zsh, etc.). You want commands to run one after another unconditionally. No special control-flow constructs are required. Concept / Approach: The semicolon '; ' separates commands on a single line. For example, 'mkdir build; cd build; make' executes three commands in sequence. Alternatives such as '&&' and '||' are conditional separators based on success or failure; they are not single-character plain separators like ';'. Step-by-Step Solution: Chain commands: echo start; date; echo doneUse conditional forms when desired: cmd1 && cmd2, or cmd1 || cmd2Group with parentheses for subshells: (cd dir; run)Redirect outputs as needed in each segment. Verification / Alternative check: Run a short chain and observe that each command executes in order. Insert an intentional failure to see that, unlike '&&', a semicolon does not prevent the next command from running. Why Other Options Are Wrong: #: Begins a comment in many shells; everything after is ignored. $: Used for variable expansion/prompt indicator; not a separator. :: A builtin no-op in some shells, not a command separator for sequences. None of the above: Incorrect because ';' is correct. Common Pitfalls: Forgetting spaces where required by certain commands, or mixing separators with unquoted special characters that the shell expands unexpectedly. Final Answer: ;

Question 16

In Unix/Linux pipelines, which command reads from standard input, writes the same data to standard output, and simultaneously copies it into a file?

Accepted Answer

Introduction / Context: Sometimes you need to both see command output on the screen and save it to a file for later analysis. Instead of running the pipeline twice or redirecting and then catting, Unix provides a filter that duplicates the stream transparently to multiple outputs. Given Data / Assumptions: You have a pipeline producing useful output on stdout. You want to preserve that output in a file without losing the live display. Standard POSIX tools are available. Concept / Approach: The 'tee' command splits its standard input and writes it to both standard output and one or more files. Common options include '-a' to append instead of overwrite. 'tee' is ideal for logging build processes, capturing diagnostic streams, or auditing scripts while maintaining interactive visibility. Step-by-Step Solution: Basic usage: cmd | tee output.logAppend to a file: cmd | tee -a output.logWrite to multiple files: cmd | tee out1.log out2.logCombine with sudo where root write is needed: cmd | sudo tee /root/out.log Verification / Alternative check: Run a pipeline such as 'dmesg | tee dmesg.txt' and confirm that output appears on screen and that the file contains identical content afterwards. Why Other Options Are Wrong: tr: Translates or deletes characters; does not duplicate streams to files. sort: Orders lines; not a duplicator. grep: Filters lines by pattern; does not copy to files and stdout simultaneously. None of the above: Incorrect because 'tee' is exactly designed for this. Common Pitfalls: Overwriting a file unintentionally without '-a', forgetting to redirect stderr separately if needed (use '2>&1' before tee), or misplacing 'sudo' which can change which side of the pipe has elevated permissions. Final Answer: tee

Question 17

In a POSIX shell, assume the current directory contains files named 'patch', 'catch', and '.ch' (a hidden file). Using the command cat ch (where globs that do not begin with a dot do not match hidden files), which filenames will be displayed?

Accepted Answer

Introduction / Context: Shell globbing rules in Unix/Linux determine which filenames a pattern expands to before a command runs. Understanding how wildcards interact with hidden files (names that begin with a dot) is essential for predictable results, especially when scripting and batch-processing files. This question explores how the pattern ch behaves with visible and hidden files. Given Data / Assumptions: The directory contains exactly three files: 'patch', 'catch', and '.ch' (the last one is a hidden file since it begins with a dot). The shell is using standard POSIX-like globbing semantics. The command used is cat ch and no shell options (like dotglob or nullglob) have been altered. Concept / Approach: By default, shell globs that do not start with a dot do not match hidden files. The pattern ch matches any filename containing the substring 'ch' anywhere in the name, but it will ignore entries that start with '.' unless the pattern itself begins with '.' or shell options are changed. Therefore, 'patch' and 'catch' match, while '.ch' does not. Step-by-Step Solution: Identify the pattern: ch (matches any characters, then 'ch', then any characters).Apply the hidden-file rule: patterns not starting with '.' do not match dotfiles.Match visible files: 'patch' (contains 'ch'), 'catch' (contains 'ch').Exclude '.ch': begins with '.', not matched by ch. Verification / Alternative check: Run printf '%s
' ch to preview the shell’s expansion. To include hidden files, you could explicitly write .ch ch or enable dotglob in bash (shopt -s dotglob) and then test again. Why Other Options Are Wrong: Only .ch: ignores visible matches; incorrect. All three: patch, catch, and .ch: would require a pattern beginning with '.' or dotglob enabled. Only patch: 'catch' also matches; incorrect. None of the above: incorrect because 'patch and catch only' is correct. Common Pitfalls: Forgetting that hidden files are excluded by default when the pattern does not start with a dot. Assuming regex semantics; globs are simpler and have different rules. Final Answer: patch and catch only.

Question 18

In the vi editor, which single-key command replaces exactly one character under the cursor with new text you type?

Accepted Answer

Introduction / Context: Vim/vi provides powerful one-keystroke editing commands for rapid text manipulation. Knowing which key performs a single-character replacement saves time and reduces errors, especially when editing configuration files or code directly on servers. Given Data / Assumptions: You are using vi or a compatible Vim in normal mode. You want to replace exactly one character at the cursor position. You will type the replacement character immediately after invoking the command. Concept / Approach: The r command in vi replaces the single character under the cursor with the next character you type. It does not enter insert mode; instead, it performs an in-place substitution and returns to normal mode instantly. This differs from commands like s (substitute one character and enter insert mode), S (change the entire line), and C (change from cursor to end of line). Step-by-Step Solution: Navigate the cursor to the character to change.Press r.Type the single replacement character (e.g., X).vi performs the replacement and remains in normal mode. Verification / Alternative check: Compare with s: pressing s deletes the character and switches to insert mode, allowing multiple characters to be typed before pressing ESC. For a strict one-character swap without entering insert mode, r is correct. Why Other Options Are Wrong: S: changes (replaces) the entire line and enters insert mode. s: substitutes one character but enters insert mode for additional input. C: changes from the cursor position to end of line. None of the above: incorrect because r is precisely the single-character replace command. Common Pitfalls: Forgetting mode: r works in normal mode only. Confusing r with s; s transitions to insert mode, which is different behavior. Final Answer: r.

Question 19

On Unix/Linux systems, which command is used to display the top portion (beginning) of a file efficiently?

Accepted Answer

Introduction / Context: When inspecting large files, it is often unnecessary to print the entire content. The Unix toolset includes commands optimized for viewing just the beginning of a file, which improves performance and readability in diagnostics, log analysis, and scripting tasks. Given Data / Assumptions: You want to read only the first few lines or bytes of a file. You prefer a purpose-built tool over piping or paging. Default behavior (first 10 lines) is acceptable unless overridden. Concept / Approach: The head command prints the first lines of a file to standard output (default: 10 lines). It supports options like -n to specify line counts (e.g., head -n 50 file.log) or -c to print bytes. This is more efficient than cat when only a preview is needed and clearer than pagers for a quick glance. Step-by-Step Solution: Use head file.txt to display the beginning.Adjust line count: head -n 20 file.txt.Use bytes if needed: head -c 512 file.bin.Combine with pipelines: dmesg | head -n 30. Verification / Alternative check: Compare with tail (end of file) to ensure you are targeting the correct portion. Use wc -l file to understand file length if context matters. Why Other Options Are Wrong: cat: outputs the entire file by default, not just the beginning. more: a pager for interactive scrolling; not specifically the “top only.” grep: searches for patterns; not a display-top tool. None of the above: incorrect because head is correct. Common Pitfalls: Confusing head with tail. Forgetting quotes when filenames contain spaces. Final Answer: head.

Question 20

Change file permissions for names starting with 'emp' and ending with 1, 2, or 3 so that the user (owner) gains execute permission: which chmod command is appropriate?

Accepted Answer

Introduction / Context: Managing permissions in Unix/Linux often involves applying changes to sets of files selected by shell globs. Understanding chmod symbolic modes and bracket patterns ensures precise, minimal changes to the correct targets without over-permissive settings. Given Data / Assumptions: Target files are named 'emp1', 'emp2', or 'emp3' (i.e., start with 'emp' and end with 1–3). Goal: add execute permission for the user (owner) only. We prefer symbolic mode for clarity (u+x). Concept / Approach: The shell glob emp[1-3] matches exactly the names ending in 1, 2, or 3. The chmod symbolic form u+x adds execute permission to the owner without altering group or others. Combining them gives chmod u+x emp[1-3], which is specific and safe. Step-by-Step Solution: Select files by pattern: emp[1-3].Decide permission change: add execute to user = u+x.Run: chmod u+x emp[1-3].Verify with: ls -l emp[1-3]. Verification / Alternative check: Run stat emp1 before and after to confirm mode changes only for the user execute bit. If scripts are in these files, test execution with ./emp1 (assuming proper shebang and path). Why Other Options Are Wrong: chmod 777 emp*: over-permissive, affects many files, not just 1–3, and changes group/others unnecessarily. chmod u+r ??? emp: malformed; adds read, not execute; and incorrect glob usage. chmod 222 emp?: sets write-only for user/group/others; also matches any single extra character, not just 1–3. None of the above: incorrect since the correct command is listed. Common Pitfalls: Using * and modifying too many files. Confusing symbolic and octal modes. Final Answer: chmod u+x emp[1-3].

Unix Questions