Question 1

On Unix/Linux systems, which command prints the absolute path of your current working directory in the shell?

Accepted Answer

Introduction / Context: Navigating the filesystem from a terminal requires awareness of where you are. The command that outputs the current working directory is fundamental for scripting, troubleshooting, and documentation of steps in Linux/Unix environments. Given Data / Assumptions: You are in a POSIX shell (bash, zsh, sh, etc.). You need the full absolute path of the directory you are currently in. Standard coreutils are available. Concept / Approach: The pwd command (print working directory) writes the absolute path of the current directory to standard output. It can be used standalone or in scripts to capture context. Some shells also provide an internal builtin with the same name; either way, functionality is the same. Step-by-Step Solution: Open a terminal.Type: pwdRead the absolute path returned, such as /home/user/projects.Combine with subshells or scripts as needed, e.g., LOGDIR=$(pwd). Verification / Alternative check: Cross-check with ls -ld . and readlink -f . where available. In most cases, pwd suffices and is portable. Why Other Options Are Wrong: dir: lists directory contents; Windows-style equivalent of ls. prompt $p$g: DOS/Windows prompt formatting; not Unix. path: shows or sets the executable search path in DOS; not current directory. None of the above: incorrect because pwd is correct. Common Pitfalls: Confusing Windows commands with Unix ones. Relative versus absolute paths; pwd gives absolute by default. Final Answer: pwd.

Question 2

Which ls option lists files ordered by modification time (most recent first) in the current directory?

Accepted Answer

Introduction / Context: Sorting by modification time is a frequent need when investigating logs, build artifacts, or recent changes. The ls command provides a flag to order entries by their last modification time so the newest items appear first, improving situational awareness on busy systems. Given Data / Assumptions: Standard GNU/BSD ls behavior is available. You want chronological sorting by modification time. No recursion or inode listing is required. Concept / Approach: Use ls -t to sort by modification time descending (newest first). Combine with -l for detailed listings or -r to reverse the sort (oldest first). For human-readable timestamps and sizes, add -h where supported. Step-by-Step Solution: List newest first: ls -tDetailed newest first: ls -ltOldest first: ls -ltrAcross subdirectories: find . -type f -printf '%T@ %p
' | sort -n (advanced). Verification / Alternative check: Compare output of ls -t with stat for specific files to confirm ordering by modification time (mtime). Why Other Options Are Wrong: ls -1: one entry per line; not a time sort. ls -i: shows inode numbers. ls -R: recursive listing; no time ordering implied. None of the above: incorrect because -t is correct. Common Pitfalls: Confusing access time (atime) or change time (ctime) with modification time (mtime). Forgetting -r reverses the order. Final Answer: ls -t.

Question 3

With grep, which anchor matches the literal pattern 'pat' only at the beginning of a line in a text file?

Accepted Answer

Introduction / Context: Anchors in regular expressions control where a pattern can match within each line. Mastering these anchors is crucial for precise searches, log filtering, and data extraction with grep and related tools like sed and awk. Given Data / Assumptions: We are using basic or extended regular expressions compatible with grep. We need to match the literal string 'pat' only when it appears at the start of a line. Multiline context is per-line (standard grep behavior). Concept / Approach: The caret anchor ^ matches the beginning of a line. Therefore, ^pat matches lines that start with 'pat'. By contrast, the dollar anchor $ matches the end of a line, so pat$ would anchor at the end, not the beginning. Step-by-Step Solution: Select beginning-of-line anchor: ^Combine with pattern: ^patCommand usage: grep '^pat' file.txtOptionally ignore case: grep -i '^pat' file.txt Verification / Alternative check: Create a sample file with lines that begin with and do not begin with 'pat' and test the command. Only those starting with the sequence will be matched. Why Other Options Are Wrong: $pat: invalid anchor usage; $ is an end-of-line anchor, not a prefix. pat$: anchors 'pat' at the end of the line. pat^: invalid for start anchoring; the caret must precede the pattern. None of the above: incorrect because ^pat is correct. Common Pitfalls: Forgetting to quote patterns that include special characters to avoid shell interpretation. Confusing ^ and $ roles. Final Answer: ^pat.

Question 4

In Unix/Linux, what is the name of the interface that sits between the user and the operating system kernel, interpreting commands and launching programs?

Accepted Answer

Introduction / Context: Unix/Linux users interact with the operating system primarily through a command interpreter that reads input, parses commands, and starts processes. Recognizing this component clarifies how scripts run, how environment variables are applied, and why different shells offer distinct features. Given Data / Assumptions: We are discussing the user-level command interface. Examples include bash, zsh, ksh, and fish. The kernel is accessed indirectly via system calls invoked by programs launched through the shell. Concept / Approach: The shell is the command-line interpreter. It accepts user commands (interactive) or reads scripts (batch), expands wildcards, performs redirection/pipelining, sets environment variables, and launches programs. Config files like ~/.profile or ~/.bashrc configure shell behavior, but they are not the interface itself. Step-by-Step Solution: Identify the user–OS interface component: shell.Give examples: /bin/bash, /bin/zsh.Note responsibilities: parsing, expansion, execution, job control.Different shells provide differing syntax and features. Verification / Alternative check: Run echo $SHELL to see your login shell. Use chsh to change it where permitted. Launch a subshell with bash or zsh to experience differences. Why Other Options Are Wrong: logic: not a Unix interface term. profile: configuration file concept, not the interpreter. erxc: not a standard Unix term. None of the above: incorrect because 'shell' is the correct term. Common Pitfalls: Confusing the shell with the terminal emulator (e.g., GNOME Terminal or iTerm2). Assuming all shells behave identically; portability matters in scripts. Final Answer: shell.

Question 5

Which chmod command removes read permission on the file 'note' for both the group and others, without changing any other bits?

Accepted Answer

Introduction / Context: File permissions in Unix/Linux are separated into owner (user), group, and others. Modifying only specific bits for group and others is common when securing documents. Using symbolic modes in chmod expresses exactly which permissions to add or remove without affecting unrelated bits. Given Data / Assumptions: Target file is named 'note'. Goal: remove read permission for both group and others. Do not alter user (owner) permissions or execute/write bits. Concept / Approach: Symbolic mode allows precise operations: g refers to group, o to others, and -r removes the read bit. Combining them yields chmod go-r note. This removes read permission for group and others simultaneously and leaves all other bits unchanged. Step-by-Step Solution: Run: chmod go-r noteVerify: ls -l note (check the permission string, e.g., rwx------/rw------- depending on previous state)Confirm that only group/others read bits changed.Adjust further if necessary (e.g., chmod o-w note) for additional hardening. Verification / Alternative check: Compare stat note output before and after. Only the group and others read bits should differ. Optionally test access from a non-owner account to validate behavior. Why Other Options Are Wrong: chmod go+r note: adds read permission; opposite of requirement. chmod go+rw note: adds read and write; opposite effect. chmod go-x note: removes execute, not read. None of the aboved: incorrect because chmod go-r note is correct. Common Pitfalls: Mistaking symbolic minus (-) for plus (+); plus adds, minus removes. Changing owner (user) permissions unintentionally; go- targets only group and others. Final Answer: chmod go-r note.

Question 6

In Unix/Linux, when using the long listing format (ls -l), which column shows the complete file permission string and file type indicator?

Accepted Answer

Introduction / Context: Understanding the output of the 'ls -l' command is foundational for Unix/Linux administration. The long listing format prints multiple columns: permissions and type, link count, owner, group, size, timestamp, and name. Knowing exactly where permissions appear helps you audit access rights and troubleshoot 'permission denied' errors quickly. Given Data / Assumptions: The command used is: ls -l Standard output layout is assumed (no custom --time-style or -o/-g variants). Goal: identify which column contains the permission string and file type indicator. Concept / Approach: In the default long format, the very first column shows a ten-character field: one character for file type (for example, '-' regular, 'd' directory, 'l' symlink), followed by nine characters describing user, group, and others permissions (for example, 'rwxr-xr--'). SELinux or ACL indicators may appear after the permissions (for example, a '+' if extended ACLs exist), but the core permission/type information remains in this first field. Step-by-Step Solution: Run: ls -l /pathInspect the leftmost field (column 1), for example: '-rwxr-xr--'.Interpret file type: leading character '-'/'d'/'l'/'c'/'b'/'p'/'s'.Interpret permissions: rwx bits for user, group, and others in positions 2–10. Verification / Alternative check: Cross-check with 'stat filename' which prints identical permission and type details in a different format (for example, 'Access: (0754/-rwxr-xr--)'). Both must agree for the same file. Why Other Options Are Wrong: second: Shows hard link count, not permissions. third: Shows the owner (user) name or ID. fourth: Shows the group name or ID. None of the above: Incorrect because the first column is correct. Common Pitfalls: Confusing the '+' ACL marker as part of permissions, or misreading spaces as columns when filenames contain spaces (the permission field is always the first token). Final Answer: first

Question 7

On Unix/Linux, which command compares two files byte by byte to report the first difference or confirm they are identical?

Accepted Answer

Introduction / Context: File comparison is a routine task in system administration and software development. While 'diff' shows line-by-line textual changes, sometimes you need a raw, byte-level comparison to validate copies, downloads, or binary artifacts. Unix provides a minimalist tool for this exact purpose. Given Data / Assumptions: You have two files that may be identical or differ in binary content. You need a simple pass/fail or the first differing location. Human-friendly patches are not required. Concept / Approach: The 'cmp' command compares files byte by byte. With no options, it is silent if files match and reports the first byte/line where they differ if not. It is ideal for verifying integrity after copies, especially for binaries, images, and archives where textual diffs are not meaningful. Step-by-Step Solution: Run: cmp file1.bin file2.binIf no output appears, files are identical (exit status 0).If different, output includes byte and line of the first mismatch.Use 'cmp -s' for a quiet exit-status-only check in scripts. Verification / Alternative check: Compare 'sha256sum file1 file2' to confirm identical hashes. When both 'cmp' and hash agree, integrity is assured. Why Other Options Are Wrong: comp: DOS/Windows utility, not the standard Unix tool. do / ccp: Not file comparison commands on Unix/Linux. None of the above: Incorrect because 'cmp' is correct. Common Pitfalls: Using 'diff' for binaries (noisy/less useful), or forgetting that 'cmp' stops at the first difference (not a full difference report). Final Answer: cmp

Question 8

In the vi editor, what does pressing the % key do during text navigation and code editing?

Accepted Answer

Introduction / Context: Efficient navigation in vi (and Vim) includes quickly jumping between paired delimiters. This is invaluable when editing source code that contains nested parentheses (), brackets [], and braces {}. The percent key provides a direct way to verify structural balance and traverse matching pairs. Given Data / Assumptions: You are in Normal mode in vi/Vim. The cursor is on or near a delimiter character. Source text contains properly paired delimiters. Concept / Approach: Pressing '%' moves the cursor to the matching partner of the delimiter under the cursor. This works for (), [], and {} and respects nesting. If the cursor is not on a delimiter, vi searches forward on the line for one before attempting a match. This simple motion helps you inspect block boundaries, function scopes, and array indices rapidly. Step-by-Step Solution: Place the cursor on a delimiter (for example, '(' or '{').Press % to jump to its match.Use % repeatedly to toggle between the opening and closing pair.Combine with operators (for example, d% to delete to the match) for structural edits. Verification / Alternative check: In a function with nested blocks, press % at different levels and confirm that vi selects the correct matching partner each time, reflecting proper nesting logic. Why Other Options Are Wrong: Upper-left corner or first column: use 'H' or '0' respectively, not '%'. Backward to start of word: use 'b' (or 'B' for WORDs). None of the above: Incorrect because '%' matches delimiters. Common Pitfalls: Pressing % when the cursor is not on a delimiter (it may not jump as expected) or relying on % when delimiters are unbalanced, which can confuse navigation. Final Answer: to move the cursor to a matching delimiter (parenthesis, bracket, or brace)

Question 9

UNIX Text Sorting Basics  Which command sorts the lines of a text file into ascending (alphabetical) order by default?

Accepted Answer

Introduction / Context: Sorting text is a foundational UNIX task used in data processing pipelines. The standard utility for ordering lines is designed to read from files or standard input and produce sorted output to standard output, integrating seamlessly with other tools via pipes. Given Data / Assumptions: POSIX-like environment with the standard coreutils or equivalent. Default locale provides sensible collation unless otherwise specified. Goal is ascending alphabetical order without extra modifiers. Concept / Approach: The command sort performs lexicographic sorting by default in ascending order. Options can modify behavior: -r reverses the order, -n performs numeric compares, and locale variables can change collation rules. Step-by-Step Solution: Use: sort input.txt > output.txt to sort lines ascending.Combine with pipes: cat input.txt | sort | uniq for de-duplicated sorted output.For reverse order, add -r; for numeric fields, add -n or -k as needed. Verification / Alternative check: Compare outputs from sort and sort -r to see ascending vs. descending order. Use LC_ALL=C for byte-wise ordering when locale collation confuses results. Why Other Options Are Wrong: sh (Option B) is the shell; it does not sort by itself.st (Option C) is not a standard command.sort -r (Option D) explicitly requests reverse (descending) order, not ascending alphabetical by default. Common Pitfalls: Mistaking locale-sensitive sorting for errors; set LC_ALL appropriately. Forgetting to redirect output and accidentally printing to screen. Final Answer: sort

Question 10

vi Editor: Replace Text from the Cursor Forward  In the standard vi editor, which command puts you into overwrite (replace) mode so that typing replaces existing text from the cursor to the right?

Accepted Answer

Introduction / Context: vi is a modal editor: normal mode for commands, insert mode for insertion, and replace mode for overwriting. Choosing the right command speeds up edits, especially when you need to overwrite existing text starting at the cursor position. Given Data / Assumptions: Behavior of classic vi (and Vim in compatible mode). Goal: replace characters as you type, beginning at the current cursor position. User is familiar with normal-mode keystrokes. Concept / Approach: Pressing uppercase R enters replace mode. In this mode, each character you type overwrites the character under the cursor and then advances, effectively replacing text “to the right” until you exit the mode with Esc. This differs from single-character or line substitutions. Step-by-Step Solution: Position the cursor at the first character to overwrite.Press R to enter replace mode.Type the replacement text; existing characters are overwritten as you proceed.Press Esc to leave replace mode and return to normal mode. Verification / Alternative check: Try rX to see that lowercase r replaces only one character with X. Compare with C which changes (deletes) from the cursor to end-of-line and then enters insert mode, not replace mode. Why Other Options Are Wrong: r (Option A) replaces a single character only.s (Option C) deletes one character and enters insert mode (not continuous overwrite).S (Option D) substitutes the entire line (delete line, enter insert mode). Common Pitfalls: Using C when you actually want overwrite behavior (C deletes to EOL). Forgetting to exit replace mode with Esc, leading to unintended overwrites. Final Answer: R

Question 11

UNIX Filters: Identifying Stream-Processing Commands  Which of the following is not a filter (i.e., a command commonly used in pipelines to read from standard input and write to standard output)?

Accepted Answer

Introduction / Context: In UNIX, a “filter” is a program designed to read from standard input and write to standard output, making it easy to combine tools using pipelines. Recognizing which commands act as filters helps build effective command-line workflows. Given Data / Assumptions: We consider classic POSIX utilities available on most UNIX-like systems. A filter participates in pipelines using the | operator. All options listed are common text-processing tools. Concept / Approach: Commands like cat, grep, wc, and sort all read from standard input (if no file is provided) and write to standard output. Therefore, each of these is usable as a filter in pipelines, meaning none of the listed commands is “not a filter.” Step-by-Step Solution: Test each command with a pipe: e.g., cat file | grep pattern | sort | wc -l.Observe that each command consumes stdin and emits stdout.Conclude that all given commands qualify as filters. Verification / Alternative check: Run man pages (e.g., man grep, man sort) to confirm stdin/stdout usage. Try echo "text" | cat, echo "text" | wc, etc., verifying their filter behavior. Why Other Options Are Wrong: Options A–D: Each listed command is a valid filter. cat concatenates and passes through data; grep filters by pattern; wc counts lines/words/chars; sort orders lines. Common Pitfalls: Assuming cat is not a filter because it “only displays”; it still reads stdin and writes stdout. Misusing filters with binary data where text utilities expect text. Final Answer: None of the above

Question 12

UNIX Copying Multiple Files to a Sibling Directory  From inside the programs directory, which command copies the three files wb, collect, and mon into the sibling directory ../misc while keeping their names?

Accepted Answer

Introduction / Context: On UNIX-like systems, copying multiple files into a target directory is accomplished using the cp command. Understanding relative paths (such as ../misc) helps navigate and manage files efficiently across sibling directories. Given Data / Assumptions: You are currently in the programs directory. There exists a sibling directory misc one level up: ../misc. Files wb, collect, and mon reside in the current directory. Concept / Approach: Use cp followed by a list of source files and the destination directory. A relative path beginning with ../ refers to the parent directory; appending misc targets the sibling directory named misc. Step-by-Step Solution: Confirm current directory with pwd and listing with ls.Execute: cp wb collect mon ../misc.Verify: ls ../misc now shows wb, collect, mon. Verification / Alternative check: Try copying with wildcards (e.g., cp w* if patterns match). Use cp -i to prompt before overwrite or cp -v for verbose output. Why Other Options Are Wrong: Option A uses DOS syntax (copy), not UNIX cp, and repeats the destination unnecessarily.Option C again uses DOS copy and an absolute path /misc that likely is not intended.Option D uses tar, which is for archiving, not simple copying to a directory argument. Common Pitfalls: Confusing absolute /misc with relative ../misc. Overwriting existing files without -i or backups. Final Answer: cp wb collect mon ../misc

Question 13

Where Core UNIX User Commands Reside  In a typical UNIX filesystem layout, where are common commands such as date, ls, and cat stored?

Accepted Answer

Introduction / Context: UNIX organizes executable programs into standard directories so they are consistently available to all users and scripts. Knowing where core tools live helps with PATH configuration and system recovery tasks. Given Data / Assumptions: Conventional UNIX or Linux filesystem hierarchy. System adheres to historical paths for user commands. Basic tools are accessible to regular users. Concept / Approach: Essential binaries needed for single-user mode or early boot often live in /bin. Additional user commands and utilities are stored in /usr/bin. This division ensures a minimal toolset is available even if /usr is on a separate partition not yet mounted. Step-by-Step Solution: Check which ls and which date to see their locations.Observe that they resolve to /bin/ls or /usr/bin/ls depending on the distribution.Confirm similar placement for cat. Verification / Alternative check: Examine PATH with echo $PATH and list the directories. Use ls -l /bin /usr/bin to see the installed command catalogs. Why Other Options Are Wrong: /dev contains device nodes, not general commands./tmp is for temporary files./unix is not a standard directory for user commands (legacy systems might use different kernel names/paths). Common Pitfalls: Assuming all commands are in one directory; PATH often aggregates several. Overwriting critical tools in /bin can break recovery shells. Final Answer: /bin and /usr/bin directories

Question 14

Listing Files: Indicators and Multi-Column Output  Which ls invocation displays file names in multiple columns and appends indicators to classify entries (e.g., / for directories, * for executables)?

Accepted Answer

Introduction / Context: The ls command supports many options for formatting and annotation. For quick visual classification of entries and compact multi-column listing, certain flags can be combined to improve readability in wide terminals. Given Data / Assumptions: Standard UNIX ls implementation supporting -F and -x. Goal: multi-column display plus type indicators appended to names. Terminal width sufficient for columnar layout. Concept / Approach: -F appends a character to each entry indicating its type (e.g., / for directories, * for executables, @ for symlinks). -x prints entries in rows across the screen (multi-column), contrasting with -l, which is long, single-column output. Step-by-Step Solution: Run ls -F -x in a directory with mixed content.Observe multi-column output and appended indicators.Use ls -F alone for single-column indicators or ls -x alone for multi-column without indicators. Verification / Alternative check: Compare with ls -l (detailed single-column) and ls -C (multi-column by column). Some platforms combine flags differently; --classify is a GNU synonym for -F. Why Other Options Are Wrong: ls -l (Option B) shows a long listing, not multi-column.ls ~ x (Option C) is invalid syntax.Option D appears to be a mistyped command. Common Pitfalls: Confusing -x with -X (sort by extension on some systems). Relying on colorization alone; indicators are useful in monochrome sessions. Final Answer: ls -F -x

Question 15

Navigating Up One Directory Level in UNIX Shells  Which command changes the current working directory to its parent (one level up)?

Accepted Answer

Introduction / Context: Command-line navigation relies on relative and absolute paths. Moving to the parent directory is a frequent task when traversing project trees or system hierarchies on UNIX-like systems. Given Data / Assumptions: POSIX shell behavior for cd. .. represents the parent directory in UNIX filepath semantics. User has execute permissions on the parent directory. Concept / Approach: cd .. instructs the shell to change into the directory referenced by .., which is the parent of the current working directory. This relative notation is consistent across UNIX shells (sh, bash, zsh, etc.). Step-by-Step Solution: Check current directory: pwd.Execute cd ...Confirm new location with pwd; path now reflects the parent directory. Verification / Alternative check: Use cd - to jump back to the previous directory and verify movement. Use ls -a to see the special entries . (current) and .. (parent). Why Other Options Are Wrong: cd alone goes to your home directory, not up one level.cd/ is not a standard UNIX idiom; cd / (with a space) changes to root.chdir may exist as a synonym on some systems, but without an argument it behaves like cd and with an argument it requires .. to target the parent; the canonical answer here is cd ... Common Pitfalls: Accidentally typing Windows-style paths (backslashes) instead of UNIX forward slashes. Confusing cd .. with cd ../.., which goes up two levels. Final Answer: cd ..

Question 16

UNIX vi editor: Which :set option enables on-screen line numbers for every line while editing (for example, to assist with navigation and referencing specific lines)?

Accepted Answer

Introduction / Context: When working in the UNIX vi editor, it is often helpful to display line numbers beside each line of text. This aids navigation, error reporting, and collaboration because commands like “:42” or “:1,10” become clearer when you can see the exact line indices. The vi/vim configuration uses the :set command to toggle editor options such as numbering, case sensitivity, and more. Given Data / Assumptions: You are editing a file in vi (or vim in vi-compatibility mode). You want persistent line numbers in the display area (not just in status messages). The question asks for the short option keyword used with :set. Concept / Approach: In classic vi, line numbers are enabled with the option named “number”. The short mnemonic for that option is “nu”. You can toggle it by entering command-line mode and typing :set nu to turn it on or :set nonu to turn it off. Vim additionally supports relative numbering (:set relativenumber), but the base, most universal option remains :set number (or :set nu). Step-by-Step Solution: Enter command-line mode by pressing colon.Type “set nu” and press Enter to enable line numbers.Verify that each screen line now shows a numeric index to the left of the text area.Optionally disable numbering with “:set nonu” if you no longer need it. Verification / Alternative check: Use :set number to see the same effect using the full option name. Run :set? number to query the current state; vi/vim reports whether the option is set or not. Why Other Options Are Wrong: nm: not a valid vi option for numbering. ic: stands for “ignorecase” in searches, unrelated to numbering. li: not the standard numbering option. None of the above: incorrect because “nu” is correct. Common Pitfalls: Confusing “nu” with “relativenumber” in vim; forgetting to prefix with colon in command-line mode; expecting numbering without issuing :set or editing ~/.vimrc to enable it permanently. Final Answer: nu

Question 17

Linux/UNIX file listing: Which command lists all files whose names end with the extension “.lst”, showing a detailed long listing for each match?

Accepted Answer

Introduction / Context: Command-line globbing patterns are crucial for filtering files by name. In Linux/UNIX shells, the asterisk * and other special characters expand to sets of filenames before the command runs. The ls utility then lists those files. Understanding which pattern truly selects files with a specific extension avoids accidental matches and incorrect outputs. Given Data / Assumptions: You want only filenames ending in “.lst”. You also want a long listing (permissions, ownership, size, timestamps). Globbing is performed by the shell, not by ls itself. Concept / Approach: The pattern “.lst” matches any file whose basename ends in the literal characters “.lst”. The ls -l flag produces a long listing. Other patterns here either select different names or are malformed for the stated goal. Therefore, “ls -l *.lst” precisely expresses “detailed listing of all .lst files.” Step-by-Step Solution: Identify the extension constraint: must end with “.lst”.Use the wildcard syntax: *.lst to match that suffix.Add -l to request long-format details.Run “ls -l *.lst” in the target directory. Verification / Alternative check: Run “echo *.lst” to see expanded matches. Compare “ls .lst” (short listing) versus “ls -l .lst” (long listing) to verify output differences. Why Other Options Are Wrong: ls lst: matches names beginning with “lst”, not ending in “.lst”. ls .: matches names with any dot, far broader than “.lst”. ls [lst]: matches names ending in one of the characters l, s, or t, not the string “.lst”. None of the above: incorrect because option A is correct. Common Pitfalls: Quoting the pattern (e.g., ".lst") prevents shell expansion when not desired; forgetting that hidden files (starting with a dot) are not matched by “” unless your shell option dotglob is set. Final Answer: ls -l *.lst

Question 18

UNIX shells history: Which shell was the earliest and became the most widely used default shell on classic UNIX systems?

Accepted Answer

Introduction / Context: Shells are command interpreters that provide the user interface to UNIX. Historically, several shells evolved with different syntax and features. Recognizing their origins and defaults helps with scripting portability and legacy system maintenance. Given Data / Assumptions: The question asks for the earliest and most widely used shell that shipped with UNIX. We distinguish between Bourne (sh), C shell (csh), and Korn shell (ksh). We focus on historical defaults on System V and earlier releases. Concept / Approach: The Bourne shell (sh), created by Stephen Bourne at Bell Labs, was the standard shell on early UNIX and became the baseline for shell scripting. Later, the C shell (csh) added C-like syntax and interactive features, and the Korn shell (ksh) improved on sh with advanced scripting. Nevertheless, sh remained the canonical “earliest and most widely used default.” Step-by-Step Solution: Identify the earliest widely distributed default shell: sh (Bourne shell).Compare alternatives: csh and ksh were later and not the original defaults system-wide.Select Bourne shell as the correct choice. Verification / Alternative check: On many UNIX derivatives, /bin/sh links to the system’s default POSIX shell; historically, this derived from the Bourne shell lineage, confirming its foundational role. Why Other Options Are Wrong: C shell: influential but later and not the earliest default. Korn shell: later enhancement; not the original standard. Smith shell: not a historical UNIX shell. None: incorrect because Bourne shell is correct. Common Pitfalls: Confusing interactive convenience (csh history, aliases) with historical default status; assuming modern /bin/sh always equals bash—implementations vary. Final Answer: Bourne shell

Question 19

vi/vim search navigation: In the vi editor, which single-character command initiates a forward search for a text pattern from the current cursor position?

Accepted Answer

Introduction / Context: Efficient navigation and searching are central to productivity in vi/vim. The editor uses concise keystrokes to start searches in the forward or backward direction and to repeat them without retyping the pattern. Given Data / Assumptions: You are in normal mode (not insert mode). You want to search from the cursor forward through the buffer. You will type a pattern after the initiating keystroke. Concept / Approach: In vi, the forward search command is “/”. After pressing “/”, you type the pattern and press Enter. The backward search equivalent is “?”. To repeat the last search in the same direction, press “n”; to reverse direction, press “N”. The doubled forms “//” and “??” are not the defined initiators; the first slash or question mark begins the command, and the rest are treated as part of the pattern. Step-by-Step Solution: Ensure you are in normal mode (press Esc).Press “/” to start a forward search.Type your pattern (e.g., “error”) and press Enter.Use “n” to jump to the next occurrence, “N” for the previous occurrence. Verification / Alternative check: Try “?” with the same pattern to verify that it searches backward; observe the difference in match direction while using n/N. Why Other Options Are Wrong: ? initiates backward search. // and ?? are not separate commands; the extra character becomes part of the search string. None: incorrect because “/” is correct. Common Pitfalls: Remaining in insert mode; forgetting to press Enter after typing the pattern; misunderstanding n/N direction behavior. Final Answer: /

Question 20

Multi-user UNIX: Which command displays information about all users who are currently logged in to the system (terminals or sessions)?

Accepted Answer

Introduction / Context: UNIX is a multi-user operating system. Administrators and users frequently need to see who is presently logged in, from which terminals or pseudo-terminals, and sometimes at what times, for collaboration or troubleshooting sessions. Given Data / Assumptions: You are on a multi-user UNIX or Linux system. You want a system-wide list of current logins, not just your shell session. Standard coreutils and traditional UNIX commands are available. Concept / Approach: The command “who” lists all logged-in users with their terminals and login times. The variant “who am i” (or “whoami” as a different command) pertains to your current effective user/session only. The command “which” traces the path to executables in your PATH and is unrelated. The text “1 /u” is not a valid command in this context. Step-by-Step Solution: Open a shell and type “who”.Review the output lines, each corresponding to a logged-in user/session.Optionally use “w” for more detail (processes and load), or “users” for just usernames. Verification / Alternative check: Compare “who” with “w”: the latter shows CPU usage and the command currently running. “who am i” returns information about your current session line only. Why Other Options Are Wrong: which: finds executables, not users. who am i: only your session, not all users. 1 /u: not a valid command. None: incorrect because “who” is correct. Common Pitfalls: Confusing “whoami” (single word) with “who am i”; misinterpreting pseudo-terminals (pts/0, pts/1) as remote logins when they may be local terminal emulators. Final Answer: who

Unix Questions