Question 1

In UNIX-style permissions, which chmod octal sets: owner = read/write/execute, group = read/execute, others = read/execute?

Accepted Answer

Introduction / Context: File permissions on UNIX and Linux systems are commonly set using octal notation with chmod. Each digit represents a triad of permissions (read, write, execute) for owner, group, and others. Mastering octal mappings streamlines secure defaults for scripts, binaries, and web content. Given Data / Assumptions: Desired permissions: owner = rwx, group = r-x, others = r-x. Octal mapping: r=4, w=2, x=1 per position. Order: owner, group, others. Concept / Approach: Compute each triad: owner rwx = 4+2+1 = 7; group r-x = 4+0+1 = 5; others r-x = 4+0+1 = 5. Concatenate digits as owner/group/others to obtain 755. This is a common setting for executable scripts and directories where users should traverse but not modify. Step-by-Step Solution: Owner: rwx => 4+2+1 = 7.Group: r-x => 4+0+1 = 5.Others: r-x => 4+0+1 = 5.Final chmod octal = 755. Verification / Alternative check: Command example: chmod 755 file then verify with ls -l, which should display -rwxr-xr-x for a regular file. Why Other Options Are Wrong: 000: no permissions at all. 744: group/others are read-only (r--), not r-x. 555: everyone read/execute; owner lacks write. None of the above: incorrect because 755 matches exactly. Common Pitfalls: Confusing symbolic (u=rwx,g=rx,o=rx) with octal forms. Setting directories to 644, breaking traversal; directories need execute to enter. Final Answer: 755.

Question 2

In UNIX 'du' usage, which option displays the number of blocks used by a file (summarized usage)?

Accepted Answer

Introduction / Context: The du (disk usage) command reports filesystem usage in blocks or human-readable units. Choosing the correct option lets administrators quickly summarize consumption by a file or directory, which is crucial for quota checks and cleanup tasks on multi-user systems. Given Data / Assumptions: We are referring to standard du behavior (POSIX-like). Goal: summarize the number of blocks used (not a recursive detailed list). Options presented mimic common du switches. Concept / Approach: du -s prints a summary for each argument—effectively the total blocks used by that file or directory, instead of listing every subentry. Other switches: -c adds a grand total line, -i (on some platforms) reports inode usage, and -d limits depth (GNU extension), but none replace the summary role of -s. Step-by-Step Solution: Identify the need: single summary of blocks used.Map requirement to du option: -s (summary).Note alternatives provide different behaviors (totals, inodes, depth).Choose -s. Verification / Alternative check: Example: du -s /var/log outputs a single number and path, representing total blocks used by /var/log, confirming the summary behavior. Why Other Options Are Wrong: -c: adds cumulative total but still lists entries unless combined with -s. -i: inode counts, not blocks. -d: depth limit; not a summary by itself. None of the above: incorrect because -s is correct. Common Pitfalls: Confusing du with ls -s, which shows per-file block sizes. Forgetting human-readable option (-h) for MB/GB formatting when needed. Final Answer: -s.

Question 3

On UNIX/Linux systems, which ps option shows a full-format listing, including the entire command line of each process?

Accepted Answer

Introduction / Context: Process inspection is a routine admin task. The ps command displays process information, and the ability to see the full command and its arguments is crucial for troubleshooting services, scripts, and rogue processes. Given Data / Assumptions: Standard UNIX/Linux ps semantics (System V style) are assumed. Goal: show the entire command line (args), owner, PID, and related columns. Common short options are listed. Concept / Approach: The -f (full) option prints a fuller set of columns, typically including UID, PID, PPID, C, STIME, TTY, TIME, and CMD with arguments. Other listed options (-1, -2, -4) do not represent standard System V ps flags for showing the command line; on GNU, long options like -e and -f are common for “everything, full.” Step-by-Step Solution: Identify the need: view full command/arguments.Recall ps flags: -f provides full format.Choose -f; combine with -e or -A if all processes are needed.Example: ps -ef. Verification / Alternative check: Running ps -ef on Linux shows a CMD column containing the complete invoked command and arguments, verifying the option choice. Why Other Options Are Wrong: -1, -2, -4: not the standard flag for full listing; meanings vary or may be unsupported. None of the above: incorrect because -f is correct and widely used. Common Pitfalls: Mistaking BSD-style flags (aux) for System V style (-ef); both work but use different syntax. Truncated display in narrow terminals; use wide terminals or ps -eo custom formats. Final Answer: -f.

Question 4

Which UNIX command is used to display a file's contents in octal (and other base) representations?

Accepted Answer

Introduction / Context: Inspecting raw file data is a common need when debugging encodings, binary formats, or control characters. UNIX provides tools to dump file contents in octal, hexadecimal, and ASCII, enabling byte-level verification independent of text encodings or editors. Given Data / Assumptions: We need a standard utility to output bytes numerically. Compatibility with POSIX environments is implied. Command should support octal natively. Concept / Approach: od stands for “octal dump.” It can print data in octal by default and also in hex or character formats using options (e.g., -t x1 for hex bytes, -c for characters). The other choices are not standard UNIX utilities for octal dumps: cd changes directories; of and oct are not standard commands. Step-by-Step Solution: Select the utility explicitly designed for octal dumps: od.Use options as needed (e.g., od -An -t o1 file) for pure octal bytes.Verify output corresponds to byte values.Apply to binary or text files as required. Verification / Alternative check: Running od -c /bin/sh | head demonstrates character and octal output, confirming the command's purpose. Why Other Options Are Wrong: cd: directory navigation only. of, oct: nonstandard/incorrect command names. None of the above: incorrect because od is correct. Common Pitfalls: Misreading base; use -t to specify exact type and width. Forgetting to suppress addresses with -An when parsing programmatically. Final Answer: od.

Question 5

In UNIX/Linux file permissions, what does the second permission triad (e.g., r--) indicate for the file's group?

Accepted Answer

Introduction / Context: UNIX file metadata shows three permission triads in ls -l output: owner, group, and others. Correctly interpreting the second triad is essential for understanding which users can read, write, or execute a file within a shared group, influencing collaboration and security settings. Given Data / Assumptions: Standard permission string like -rw-r--r--. Order of triads: owner, group, others. Notation r=read, w=write, x=execute, -=no permission. Concept / Approach: The second triad applies to the file's owning group. If it reads r--, it grants the group read-only access (no write, no execute). The first triad affects the owner; the third affects all other users. Therefore, r-- in the middle position means “group has read permission only.” Step-by-Step Solution: Identify triad positions: owner, group, others.Read the second triad value: r--.Map r-- to read-only permission.Conclude: group read-only. Verification / Alternative check: Use stat -c %A file (Linux) or ls -l to confirm triad positions; modify with chmod g+r,g-wx file to explicitly set group read-only and verify result. Why Other Options Are Wrong: other has read permission only: refers to the third triad, not the second. owner has read permission only: refers to the first triad. group has write permission only: would be -w-, not r--. None of the above: incorrect because the group interpretation is clear. Common Pitfalls: Miscounting triad positions, especially with directory entries. Forgetting that execute on directories controls traversal, not execution. Final Answer: group has read permission only.

Question 6

In POSIX shells, which special variable expands to the process ID (PID) of the most recently executed background job?

Accepted Answer

Introduction / Context: Scripting often requires capturing the PID of a background task to wait on it, send signals, or monitor its status. POSIX shells expose special parameters for this purpose, enabling robust job control and automation patterns without resorting to parsing ps output. Given Data / Assumptions: Shell: sh/bash/ksh/zsh with POSIX semantics. A background job was started using command &. We need the variable that holds that job's PID. Concept / Approach: $! expands to the PID of the most recently executed background pipeline. Other parameters have different meanings: $# is the number of positional parameters, $0 is the script's name, and $ expands positional parameters as a single word. Thus, $! is the correct way to capture and reference a background job's process ID immediately after launching it. Step-by-Step Solution: Start a job in background: sleep 60 &Immediately capture its PID: pid=$!Use PID as needed: wait "$pid" or kill "$pid".Confirm behavior by echoing $! right after &. Verification / Alternative check: Test snippet: ( sleep 3 ) & echo $! prints the PID, demonstrating the variable's semantics in interactive and script contexts. Why Other Options Are Wrong: $#: count of arguments to the script/function. $0: name of the shell or script. $*: all positional parameters; not a PID. None of the above: incorrect because $! is standard. Common Pitfalls: Referencing $! too late; another background job might overwrite it. Confusing $! with job control %1 notation used by the shell built-ins. Final Answer: $!.

Question 7

In Unix/Linux command-line usage, which command is specifically used to identify the type of a file based on its content and metadata (rather than just the filename extension)?

Accepted Answer

Introduction / Context: On Unix and Linux systems, knowing the actual type of a file is essential for troubleshooting, scripting, and security hardening. Filenames do not reliably indicate content; for example, a file named note.txt could be a binary. The command that inspects content and metadata to report a human-friendly type is purpose-built for this task. Given Data / Assumptions: You are working in a Unix-like shell (for example, bash, zsh). You need a dependable way to determine what a file actually contains. Relying only on extensions is not sufficient or safe. Concept / Approach: The file command uses a database of magic numbers and heuristic checks to identify file types by content, optionally following symlinks and examining encoding. It reports types such as ELF executable, JPEG image, ASCII text with UTF-8 encoding, gzip-compressed data, and more. This is fundamentally different from listing, paging, or concatenating files. Step-by-Step Solution: Run: file mydata.binObserve output such as: 'mydata.bin: ELF 64-bit LSB executable'. Use options like -i to show MIME type: file -i mydata.binIntegrate in scripts to branch logic based on detected type. Verification / Alternative check: Cross-check with tools specific to the suspected format (for example, strings, hexdump, identify for images). The file result should match the specialized tool's conclusion about format and encoding. Why Other Options Are Wrong: ls: Lists directory contents and attributes; it does not infer file type by content. cat: Prints file contents; it does not classify them. more: Paginates text to the terminal; not a type detector. None of the above: Incorrect because file is exactly the dedicated utility. Common Pitfalls: Assuming an extension dictates type, running file on symlinks without -L if you need the target's type, or ignoring compressed/archived layers where file may report the container (for example, 'gzip compressed data'). Final Answer: file

Question 8

In the vi editor on Unix/Linux, which command syntax performs a forward search for the pattern ‘‘pat’’ from the current cursor position?

Accepted Answer

Introduction / Context: Searching efficiently inside the vi (or Vim) editor is a core skill for developers and administrators. Vi supports forward and backward incremental searches using concise keystrokes, enabling rapid navigation through large configuration files, logs, and source code. Given Data / Assumptions: You are editing in command mode within vi. You wish to find the next occurrence of a text pattern 'pat'. Standard vi search conventions apply (case sensitivity may depend on options). Concept / Approach: In vi, forward search uses a slash followed by the pattern. Backward search uses a question mark. The colon prefix introduces ex-commands (for example, :w, :q, :%s/old/new/g) and is not used for plain search initiation. After a search, n and N repeat the search in the same or opposite direction respectively. Step-by-Step Solution: Press / then type pat and hit Enter to search forward.Use n to jump to the next match forward, N to go to the previous match.Use ?pat to search backward if needed.Escape special characters or use \v (in Vim) for very magic regex modes. Verification / Alternative check: Open a file containing multiple 'pat' occurrences; invoke /pat and confirm the cursor jumps forward to each occurrence with n. Reverse direction using N to validate the behavior. Why Other Options Are Wrong: :pat: The colon starts ex-commands; this is not the search syntax. ?pat: This triggers a backward search, not forward. All of the above: Mutually contradictory; only /pat is forward search. Common Pitfalls: Remaining in insert mode (press Esc first), forgetting that searches are case-sensitive unless 'ignorecase' or 'smartcase' is set, or leaving metacharacters unescaped when they are interpreted as regex tokens. Final Answer: /pat

Question 9

On Unix/Linux, which command is used to create files and/or update only the access and modification timestamps without changing content?

Accepted Answer

Introduction / Context: File timestamps (atime for last access and mtime for last modification) are frequently used by backup systems, build tools, and compliance workflows. Sometimes you need to update these times without editing the file's data, or create an empty file if it does not already exist. Unix provides a simple command for both tasks. Given Data / Assumptions: You need to refresh timestamps for scheduling or build triggers. The file may or may not exist beforehand. No change to the file's content is required. Concept / Approach: The touch command updates atime and mtime on existing files and creates zero-length files if they do not exist. Options like -a, -m, -t, and -r provide fine-grained control over which times are changed and which reference is used. This is preferred over modifying content merely to bump timestamps, which can corrupt data or interfere with checksums. Step-by-Step Solution: Update both times to now: touch report.logOnly access time: touch -a report.logOnly modification time: touch -m report.logSet an explicit time: touch -t 202501011230 file.txt (format YYYYMMDDhhmm[.ss]) Verification / Alternative check: Run stat file.txt (or ls -l --time-style=full-iso) before and after touch to confirm atime/mtime changes without altering file size or checksum. Why Other Options Are Wrong: wc: Counts lines/words/bytes; does not change timestamps. grep: Searches text; does not adjust file metadata. cat: Concatenates or displays contents; writing through cat alters data, not just timestamps. None of the above: Incorrect because touch performs the timestamp update. Common Pitfalls: Misunderstanding filesystem mount options like noatime/relatime that affect access time behavior, or using incorrect -t format leading to failed updates. Final Answer: touch

Question 10

For the Unix/Linux touch command, which specific option targets changing only the access time (atime) of a file?

Accepted Answer

Introduction / Context: While touch can modify both access and modification timestamps, administrators and build systems often need to control them independently. Selecting the correct switch avoids unintended changes and preserves audit trails where mtime should remain untouched. Given Data / Assumptions: You intend to adjust only atime. mtime should remain unchanged unless explicitly set. Standard GNU/BSD touch semantics apply. Concept / Approach: The -a option tells touch to change the access time only. The -m option (not listed in distractors) changes the modification time only. The -t option supplies an explicit timestamp but, by itself, affects both atime and mtime unless combined with -a or -m. Options -b and -h are unrelated here (-h affects symlink timestamps on some systems). Step-by-Step Solution: Inspect current times: stat notes.txtUpdate only atime to now: touch -a notes.txtSet only atime to a specific time: touch -a -t 202507201200 notes.txtRe-check with stat to confirm mtime is unchanged. Verification / Alternative check: Compare stat output before and after running 'touch -a'. You should see atime updated while mtime stays the same, proving that -a is the correct, targeted switch. Why Other Options Are Wrong: -t: Provides a timestamp but affects both times unless paired with -a/-m. -b: Not a standard touch option for times. -h: On some systems operates on the symlink itself; not a time selector. None of the above: Incorrect because -a is the correct choice. Common Pitfalls: Forgetting that -t requires format YYYYMMDDhhmm[.ss], and overlooking mount options like relatime which may delay atime updates on access. Final Answer: -a

Question 11

On multi-user Unix/Linux systems, which command broadcasts a message to all users currently logged in (for example, for maintenance notices)?

Accepted Answer

Introduction / Context: System administrators often need to alert every active user about impending maintenance, shutdowns, or policy changes. Unix-like systems provide terminal-messaging utilities that can target one user, a group, or everyone with an interactive session. Given Data / Assumptions: Multiple users are logged in to terminals or pseudo-terminals. You need immediate, real-time notification. Permissions allow writing to user terminals. Concept / Approach: The wall (write all) command sends a message to all logged-in users by writing to their terminals. By contrast, write targets a single user (for example, write alice), mail delivers e-mail and is not instantaneous, and mesg controls whether a user's terminal can receive messages (mesg y/n). For urgent broadcast communication, wall is the canonical choice. Step-by-Step Solution: Compose a message and broadcast: echo "System maintenance in 5 minutes" | sudo wallVerify delivery: check multiple terminals for the broadcast banner.If some users do not receive it, confirm mesg settings and terminal availability.Follow up via mail if a persistent record is needed. Verification / Alternative check: Run who or w to list logged-in users and their TTYs. After sending with wall, observe that all TTYs display the same message, confirming system-wide broadcast. Why Other Options Are Wrong: write: One-to-one messaging; not a broadcast. mail: Asynchronous e-mail; not immediate terminal broadcast. mesg: Toggles permission to receive writes; not a messaging command itself. None of the above: Incorrect because wall accomplishes the broadcast. Common Pitfalls: Assuming wall overrides a user's mesg n setting or forgetting sudo/root may be required to reach all terminals on some systems. Final Answer: wall

Question 12

Which exact wc (word count) option counts only the number of bytes/characters in a file on Unix/Linux?

Accepted Answer

Introduction / Context: The wc utility summarizes textual statistics and is commonly used in scripts and quick checks. Understanding its switches helps you retrieve only the metric you need—lines, words, or bytes/characters—without extra parsing. Given Data / Assumptions: You need the size as counted by bytes/characters. You are operating on a regular text or binary file. Locale and encoding may affect the interpretation of 'character'; wc -c counts bytes. Concept / Approach: wc -c reports the number of bytes in the input. On many systems this corresponds to character count for single-byte encodings. Other key options include -l for lines and -w for words. There is no standard '-r' or '- 1' option; those are distractors. Using the correct flag prevents confusion and enables reliable scripting logic. Step-by-Step Solution: Run: wc -c file.txtCapture output like: '12345 file.txt'To get only the number, use command substitution: wc -c < file.txtCombine with cut/awk if you provided a filename and need to strip it. Verification / Alternative check: Compare with stat -c %s file.txt (GNU) which reports size in bytes. The values should match for regular files not involving transformations like newline conversions. Why Other Options Are Wrong: wc -w: Counts words, not bytes. wc -r: Not a standard option. wc - 1: Not valid syntax; possibly a mistaken -l (lines). None of the above: Incorrect because -c is the correct flag. Common Pitfalls: Confusing bytes with characters in multibyte encodings; for true character counts, use locale-aware tools like awk or iconv in combination with wc where appropriate. Final Answer: wc -c

Question 13

On Unix/Linux, which command is designed to extract specific columns or fields from each line of a file or standard input?

Accepted Answer

Introduction / Context: Processing delimited text (CSV, TSV, logs) often requires selecting particular fields. Unix pipelines favor small utilities that do one job well. The command that slices columns or character ranges directly from lines is concise and efficient for this purpose. Given Data / Assumptions: Input lines are structured (for example, comma- or tab-delimited). You know the field positions and delimiter. You want a pure extraction without pattern filtering or merging. Concept / Approach: The cut command extracts selected fields (-f) or character positions (-c) using a specified delimiter (-d). It is ideal for simple, position-based selection. For more complex parsing (quotes, variable delimiters), consider awk, but for straightforward column extraction, cut is the canonical tool. Step-by-Step Solution: Select columns 1 and 3 from comma-separated data: cut -d ',' -f 1,3 data.csvExtract characters 1-10 from each line: cut -c 1-10 file.txtCombine with pipes: cat access.log | cut -d ' ' -f 1Redirect results to a new file if needed: ... > subset.txt Verification / Alternative check: Use head and echo to preview a few lines, then run cut and manually verify fields align with the delimiter you chose. If fields contain the delimiter inside quotes, switch to awk for robustness. Why Other Options Are Wrong: grep: Finds lines matching patterns; does not extract fixed fields. paste: Merges lines/columns from files; the inverse of cut in many workflows. cat: Displays contents; no field selection. None of the above: Incorrect because cut is purpose-built for column extraction. Common Pitfalls: Forgetting to set the delimiter with -d, assuming tabs by default when input is comma-separated, or expecting cut to handle quoted CSV intricacies. Final Answer: cut

Question 14

In the Unix/Linux cut command, which option is used to specify the field delimiter character for splitting input lines into fields?

Accepted Answer

Introduction / Context: When extracting fields with cut, the utility must know how to split each line. The delimiter can be a comma, tab, colon, or any single character. Choosing and declaring the correct delimiter is essential for accurate column extraction. Given Data / Assumptions: Your input is consistently delimited (for example, CSV with commas). You know which fields (-f) you want. You need to set the split character explicitly if it is not a tab. Concept / Approach: The -d option to cut sets the field delimiter. For example, -d ',' uses a comma; -d ':' uses a colon. Without -d, cut defaults to tab for field mode. Pair -d with -f to pick specific fields. Other letters shown here (-a, -r, -x) are not valid delimiter switches for cut. Step-by-Step Solution: Use comma as delimiter: cut -d ',' -f 2,4 data.csvUse colon for /etc/passwd style: cut -d ':' -f 1,7 /etc/passwdDefault tab delimiter: cut -f 1-3 data.tsvChain with sort/uniq for further processing. Verification / Alternative check: Print a sample line and visually count separators to ensure that the -d character matches the actual data; otherwise you will see empty or misaligned fields in output. Why Other Options Are Wrong: -a / -r / -x: Not the correct switch for specifying a delimiter in cut. None of the above: Incorrect because -d is the proper delimiter option. Common Pitfalls: Using multi-character delimiters (unsupported by cut) or forgetting to quote special shell characters such as '|' or '*' if used as delimiters in unusual cases. Final Answer: -d option

Question 15

Which redirection pipeline sends the output of the wc command (run on infile) into a new file named newfile in Unix/Linux?

Accepted Answer

Introduction / Context: Shell redirection allows you to route the standard output of a command into a file. When obtaining counts from wc for a specific source, you can supply the filename as an argument or feed it via standard input; both produce valid results but with slightly different output formats. Understanding these nuances prevents surprises in scripts. Given Data / Assumptions: You want word/line/byte counts produced by wc for 'infile'. The result must be written into a new file 'newfile'. Standard POSIX shell redirection behavior applies. Concept / Approach: Using an explicit filename argument, wc infile > newfile runs wc on that file and writes the formatted counts (including the filename) into newfile. Supplying input via stdin, wc < infile > newfile also works but omits the filename in the report. The question asks for a command that sends the counts of the file to newfile; the explicit argument form is the most straightforward and commonly taught choice. Step-by-Step Solution: Create output: wc infile > newfileInspect: cat newfile to see counts with filename label.For a bare number, use options (for example, wc -l < infile > newfile).Integrate into scripts with test conditions as needed. Verification / Alternative check: Run wc infile and compare its terminal output to the contents of newfile; they should match exactly. Then try wc < infile > newfile to observe omission of the filename, illustrating the format difference. Why Other Options Are Wrong: wc newfile: Functional but changes the output format by removing the filename; not the standard explicit form the question expects. wc infile - newfile: Invalid syntax; '-' is not an output redirection. wc infile | newfile: Pipes require a command on both sides; newfile is not a command. None of the above: Incorrect because the first command is valid and conventional. Common Pitfalls: Overwriting newfile unintentionally (use >> to append), or confusing stdin redirection with argument-driven mode when you require the filename label in output. Final Answer: wc infile >newfile

Question 16

In Unix/Linux, which rm option enables interactive mode so that the command prompts for confirmation before deleting each file?

Accepted Answer

Introduction / Context: File deletion on Unix/Linux is immediate and typically irreversible without backups. To reduce risk, the rm command provides an interactive mode that asks for confirmation for each item, making accidental mass deletions less likely—especially helpful when using wildcards. Given Data / Assumptions: You are considering a deletion affecting multiple files. Safety and confirmation are preferred over speed. You are using a POSIX-like shell environment. Concept / Approach: The -i option activates interactive prompts in rm, asking 'remove regular file 'name'?'. Some distributions also offer the more aggressive -I (capital i) to prompt once if the operation is large. The -r (or -R) option is recursive deletion for directories; it does not prompt by itself. Other flags shown (-x, -1) are not standard rm options for interactivity. Step-by-Step Solution: Preview with ls to see intended targets.Delete interactively: rm -i *.logAnswer y/n for each file as prompted.For directories: rm -ir project/ to combine recursion with prompts. Verification / Alternative check: Run a dry run using echo: echo rm -i *.log to verify expansion. Then perform rm -i and confirm that prompts appear. Use aliases (for example, alias rm='rm -i') as a safety net if desired. Why Other Options Are Wrong: -r: Enables recursion; it does not prompt unless combined with -i. -x: Not a standard rm option for interactivity. -1: Not a valid rm option; likely a distractor. None of the above: Incorrect because -i is the correct interactive switch. Common Pitfalls: Relying solely on -i but using sudo in scripts (aliases may be bypassed), or forgetting that rm -rf will remove without prompting—use with extreme caution. Final Answer: -i

Question 17

In Unix/Linux command-line usage, which command is used to list the contents of directories (i.e., show files and subdirectories)?

Accepted Answer

Introduction / Context: The ability to list files and directories is foundational when working in Unix or Linux shells. Command-line navigation, file management, and scripting all begin with knowing which tool reveals directory contents reliably and flexibly. This question checks recognition of the standard command used across most Unix-like systems to display directory listings. Given Data / Assumptions: You are in a Unix/Linux shell (e.g., bash, zsh, sh). You want to view files and subdirectories in the current or a specified path. Utilities mentioned include common but different-purpose commands. Concept / Approach: The canonical Unix command for listing directory contents is ls. It supports numerous options for formatting (e.g., -l for long listing, -a to include hidden files, -h for human-readable sizes). While other operating systems (such as DOS/Windows) use dir, on Unix/Linux the primary tool is ls. Understanding this distinction prevents cross-platform confusion when switching between shells and terminals. Step-by-Step Solution: Identify the operating environment: Unix/Linux.Recall the standard command: ls.Note useful variants: ls -la, ls -lh, ls -R.Select the option that matches the Unix listing command. Verification / Alternative check: Running ls prints the names of entries in the working directory. Using ls /etc lists contents of /etc, confirming the command's purpose. Why Other Options Are Wrong: lp: sends print jobs to the print system; not for listing directories. dir: primarily a DOS/Windows command; on some Unix variants it may exist but is an alias to ls, not the canonical answer. tar: archives files; does not list directory contents by default. None of the above: incorrect because ls is correct. Common Pitfalls: Confusing Windows' dir with Unix' ls. Forgetting flags to reveal hidden dotfiles (use -a). Final Answer: ls.

Question 18

In the Unix sort command (historical POSIX/legacy syntax), which position option begins sorting after the nth column of the (m+1)th field?

Accepted Answer

Introduction / Context: Older Unix sort utilities (and some current implementations in legacy mode) support field/column specifications using the historical +m.n notation to set the starting key position. Understanding this syntax is valuable when you encounter classic scripts or exam questions referencing it, even though modern sort often prefers the -k option. Given Data / Assumptions: Legacy sort position syntax is being referenced. You need to start sorting after the nth column of the (m+1)th field. Fields are whitespace-delimited unless specified otherwise. Concept / Approach: In the historical format, +m.n indicates the sort key starts at field m+1, column n+1 within that field (semantics vary slightly by implementation, but exam convention treats it as “after nth column of (m+1)th field”). Therefore expressing “(m+1)th field and nth column” is commonly written as +(m+1).n. In the provided options, +(m+l).n uses l to indicate the number one, matching +(m+1).n. Step-by-Step Solution: Identify intended starting field: (m+1).Identify intended starting column offset within that field: n.Map to legacy form: +(m+1).n.Choose the option written as +(m+l).n (l standing for 1 in the exam's notation). Verification / Alternative check: Modern equivalent: sort -k $((m+1)).$((n+1)) (adjust for exact column semantics). Recognizing that the question tests legacy notation ensures you select the expression that encodes “after nth column of the (m+1)th field.” Why Other Options Are Wrong: -m.n: wrong flag; minus indicates a different (end) position in some variants. +m.n: starts at the m-th field (not m+1 as asked). + n.m+1: malformed spacing/syntax. None of the above: incorrect because the intended legacy form is present as +(m+l).n. Common Pitfalls: Mistaking legacy +POS for modern -k usage; on GNU sort, prefer -k. Off-by-one confusion between field/column indexes in different implementations. Final Answer: +(m+l).n.

Question 19

Which shell glob correctly concatenates all files whose names start with 'emp' and are followed by a single non-numeric character?

Accepted Answer

Introduction / Context: Filename expansion (globbing) in POSIX shells lets you select groups of files matching patterns without invoking full regular expressions. Understanding bracket expressions, ranges, and negation is essential for writing concise commands to process batches of files safely and correctly. Given Data / Assumptions: We are in a POSIX shell (bash/sh/ksh/zsh) with standard globbing. We want files named like empX where X is any non-digit character. We intend to concatenate these files' contents. Concept / Approach: Shell globs support bracket lists and negation. Inside [], a leading ! negates the class. [!0-9] therefore matches any single character that is not 0 through 9. Prepending emp makes emp[!0-9], which matches names starting with emp followed by exactly one non-digit. To concatenate contents, use cat with that glob. If the requirement were “one or more” non-digits, you would add a trailing , but the question states a single character. Step-by-Step Solution: Select negated digit class: [!0-9].Prefix with literal 'emp': emp[!0-9].Use cat to concatenate: cat emp[!0-9].Execute to read all matching files in lexical order. Verification / Alternative check: Use printf '%s
' emp[!0-9] to preview matches safely before concatenating. This confirms the glob resolves to the intended set of filenames. Why Other Options Are Wrong: more [emp][!0-9]: matches names two characters long from character sets, not 'emp' prefix. cat emp[x-z]: restricts to letters x–z only, not all non-digits. cat emp[a-z]: matches only lowercase letters; digits excluded but overly restrictive vs “non-numeric.” None of the above: incorrect because cat emp[!0-9] is valid. Common Pitfalls: Confusing shell globs with regular expressions; their syntax differs. Forgetting that [!0-9] matches exactly one character; append for multiple. Final Answer: cat emp[!0-9].

Question 20

Which command copies all files whose names contain the string 'chap' followed by exactly two additional characters into the directory named 'progs'?

Accepted Answer

Introduction / Context: Precise filename selection is a daily task in Unix shells. The question tests familiarity with glob wildcards—particularly the question mark, which matches exactly one character—so you can target filenames of a specific pattern without over-matching unintended files. Given Data / Assumptions: We need files matching: 'chap' plus exactly two characters (e.g., chap01, chapAB). We must copy them into a directory named progs (relative or absolute path). We are using the standard cp command. Concept / Approach: In shell globs, matches any number of characters (including zero), whereas ? matches exactly one character. Therefore, the pattern for “chap followed by exactly two characters” is chap??. To copy all such files into a destination directory, use cp chap?? progs. This ensures only two-character suffixes are matched and avoids catching longer names that would include. Step-by-Step Solution: Choose wildcard for exactly one character: ?Repeat twice to require two extra characters: ??Form the glob: chap??Copy to target: cp chap?? progs Verification / Alternative check: Dry-run with printf '%s
' chap?? to preview matches. Confirm the destination exists (mkdir -p progs) before executing the copy. Why Other Options Are Wrong: cp chap progs: matches any length, not exactly two characters. cp chap[12] /progs/.: mismatched intent; selects only 'chap1' or 'chap2' and wrong destination operand. cp chap?? /progs/: invalid destination; you should specify the directory, not expand to its contents. None of the above: incorrect because cp chap?? progs is correct. Common Pitfalls: Using and unintentionally copying too many files. Forgetting to quote or preview when filenames may include spaces or special characters. Final Answer: cp chap?? progs.

Unix Questions