Question 1

chmod usage: Which option applies a permission change recursively to all files and all subdirectories under a given directory?

Accepted Answer

Introduction / Context: Managing file permissions at scale often requires changing modes on an entire directory tree. The chmod utility alters read, write, and execute bits, and offers a recursive option to apply changes to every descendant path in one command. Given Data / Assumptions: You need to change permissions for a directory and everything beneath it. You are using a standard Linux/UNIX chmod implementation. You want the correct flag that ensures recursion. Concept / Approach: The recursive option for chmod is “-R”. Example: chmod -R u+rX,go-rw /project updates permissions for all files and subdirectories of /project. Other letters in chmod denote modes (r, w, x) or symbolic operators (+, -, =), not recursion. Flags like -i or -x in this context are not valid for recursion; -x is typically a mode, not an option. Step-by-Step Solution: Identify the need: apply permissions to an entire tree.Use “chmod -R … path” to enable recursion.Verify changes on sample files to ensure the intent matches results. Verification / Alternative check: Run “find DIR -type f -exec chmod … {} +” as an alternative to tailor file-only or dir-only changes; compare with chmod -R behavior. Why Other Options Are Wrong: -1: not a chmod recursion flag. -i: not standard for recursion. -x: refers to execute bit in modes, not an option. None: incorrect because -R is correct. Common Pitfalls: Accidentally removing execute bits from directories (breaking traversal); applying world-writable modes recursively without need; forgetting to preserve special bits when required. Final Answer: -R

Question 2

Counting entries with pipes: Which pipeline correctly counts the number of directory entries listed in the current directory, producing one numeric line count?

Accepted Answer

Introduction / Context: Combining simple commands with pipes is a hallmark of UNIX philosophy. To count files in a directory, you can list them with ls and then count the resulting lines with wc. Choosing the right flags ensures the count matches expectations. Given Data / Assumptions: You are in the directory to be inspected. You want a single numeric count of entries. Standard coreutils (ls, wc) are available. Concept / Approach: “ls -l” produces a long listing with one line per entry (plus a “total …” header in many implementations). Piping to “wc -l” counts lines, providing the number of entries. While “ls -1 | wc -l” avoids the header and is often preferred, it is not among the provided options; the classic teaching example is “ls -l | wc -l”. Be aware the “total” header line may be included depending on locale/system, but in many scenarios instructors accept this pipeline as the canonical answer. Step-by-Step Solution: List directory entries with one-per-line output using “ls -l”.Pipe output to “wc -l” to count the lines.Read the final numeric result from wc. Verification / Alternative check: Use “ls -1 | wc -l” to avoid header line; compare counts. For hidden files include “ls -A” or “ls -a”. Why Other Options Are Wrong: ls | wc: counts lines, words, and bytes; not a single number unless flags are added. ls | wc -w: counts words, not entries. ls | ws -c: “ws” is not wc, and -c on wc counts bytes, not lines. None: incorrect because option B is the accepted pipeline here. Common Pitfalls: Forgetting hidden files (-a/-A); misinterpreting the “total” header; using aliases that change ls formatting. Final Answer: ls -l | wc -l

Question 3

Shell wildcards (globbing): Which wildcard pattern matches exactly one character in a filename (for example, file?.txt matches file1.txt but not file10.txt)?

Accepted Answer

Introduction / Context: Shell globbing provides powerful filename expansion. Understanding the differences between , ?, and bracket expressions enables precise selection of files, making scripts and one-liners safer and more predictable. Given Data / Assumptions: You are using a standard POSIX-like shell (bash, dash, ksh). You want to match exactly one character at a specific position. You do not wish to use regular expressions—this is shell globbing. Concept / Approach: The wildcard “?” matches exactly one character. The asterisk “” matches zero or more characters. Bracket classes like “[ijk]” match exactly one character but only from the listed set i, j, or k. A negated class like “[!ijk]” matches exactly one character that is not in the set. Therefore, the general-purpose “single character wildcard” is “?”. Step-by-Step Solution: Identify the requirement: any single character, unrestricted.Choose the “?” wildcard, which fits this requirement.Use examples: “file?.txt” matches “file1.txt” and “fileA.txt”, but not “file10.txt”. Verification / Alternative check: Echo patterns to see expansions: “echo file?.txt” and compare to “echo file.txt” to visualize differences in matching. Why Other Options Are Wrong: : matches any number of characters (including none), not exactly one. [ijk]: matches exactly one, but only i, j, or k. [!ijk]: matches exactly one character that is not i, j, or k. None: incorrect because “?” is correct. Common Pitfalls: Confusing globbing with regex; forgetting that hidden files (dotfiles) are not matched by “” or “?” unless dotglob is set or the pattern begins with a dot. Final Answer: ?

Question 4

Listing hidden files: Which ls option displays hidden files (names starting with a dot) together with other files in the current directory?

Accepted Answer

Introduction / Context: By convention, UNIX-like systems treat filenames beginning with a dot as hidden. Many configuration files and directories use this convention. To audit or troubleshoot effectively, you often need to include these hidden entries in directory listings. Given Data / Assumptions: You are using the ls utility to list directory contents. Some entries begin with a leading dot. You want to display both hidden and non-hidden files. Concept / Approach: The “-a” option tells ls to include all entries, including those starting with “.” (dot). Other useful options: “-A” includes almost all, excluding “.” and “..”. The “-l” option sets long format; “-F” appends indicators like “/” for directories; “-x” changes multi-column layout by rows. None of these, except -a or -A, affects hidden file visibility. Step-by-Step Solution: Run “ls -a” to include hidden files.Optionally combine with “-l” for detail: “ls -la”.Inspect dot-prefixed files such as .bashrc, .gitignore, or .config/. Verification / Alternative check: Compare outputs of “ls”, “ls -a”, and “ls -A” to see which entries are included. Note that “.” and “..” are shown with -a but suppressed with -A. Why Other Options Are Wrong: -l: long format only. -x: layout change, not visibility. -F: classifies entries but does not show hidden ones. None: incorrect because “ls -a” is correct. Common Pitfalls: Assuming “ls *” will show dotfiles (it will not without dotglob); confusing “-a” and “-A”. Final Answer: ls -a

Question 5

UNIX account security: Which system file contains the password aging fields (such as last change, minimum/maximum days, and warning periods) associated with user accounts?

Accepted Answer

Introduction / Context: Password aging enforces security by requiring users to change passwords periodically and by controlling minimum days between changes. On UNIX and Linux systems with shadow password support, sensitive password hashes and aging metadata are stored separately from world-readable user information. Given Data / Assumptions: The system uses shadow passwords (common in modern UNIX/Linux). You seek the file specifically holding password hashes and aging metadata. Typical files include /etc/passwd, /etc/shadow, and shell profiles (e.g., ~/.profile). Concept / Approach: /etc/shadow stores secure password hashes and aging fields (for example: last change date, minimum days, maximum days, warning and inactivity periods). /etc/passwd (sometimes referenced colloquially as the “password” file) holds public account data like username, UID/GID, shell, and home directory, but not the hash when shadowing is enabled. Profile files configure shell environments and are unrelated to password aging. Step-by-Step Solution: Identify the file where aging metadata resides: /etc/shadow.Recall that only privileged users can read /etc/shadow due to security sensitivity.Confirm that /etc/passwd does not contain the actual hash or aging fields in shadow setups. Verification / Alternative check: Consult “man 5 shadow” for field formats; compare with “man 5 passwd” to see the separation of concerns. Use chage to view or modify a user’s password aging settings, which reads/writes /etc/shadow. Why Other Options Are Wrong: password (/etc/passwd): lacks aging data when shadowing is used. profile: per-user shell initialization, unrelated. All the three: incorrect because only the shadow file contains password aging fields. Common Pitfalls: Confusing “passwd” (the command) with /etc/passwd; assuming you can read /etc/shadow as a regular user; overlooking PAM and chage tools that manage these fields. Final Answer: Shadow

Question 6

Unix/Linux shells — changing the current working directory (POSIX/Bourne-compatible shells)  In a POSIX/Bourne-compatible shell environment (sh, bash, ksh, dash), which built-in command is used to change the current working directory of the shell pr…

Accepted Answer

Introduction / Context: In Unix and Linux, many actions depend on the current working directory. Scripts, relative paths, and shell navigation all assume you know how to move around the filesystem. The question tests which command changes the working directory in POSIX/Bourne-compatible shells, which include sh, bash, ksh, and dash. Given Data / Assumptions: The shell is POSIX/Bourne-family (sh/bash/ksh/dash), not csh or tcsh. The action required is changing the shell’s own current directory (not launching a new process). We are choosing the standard, portable command. Concept / Approach: Changing the shell’s working directory must be done by a built-in because a separate process cannot modify the parent shell’s state. In POSIX shells, the built-in command for this is cd. Although some shells also accept chdir, cd is the standard portable form. The other names shown either do not exist or are not portable built-ins in this shell family. Step-by-Step Solution: Identify the shell family: POSIX/Bourne-compatible.Recall the portable command: cd is the built-in to change directories.Confirm that cd /path changes the working directory for the current shell session.Conclude that the correct option is cd. Verification / Alternative check: Type type cd or help cd in bash; you will see it is a shell built-in. Running pwd before and after cd will verify the directory change. Why Other Options Are Wrong: changedir: not a standard command in POSIX shells. chdir: a C library/system call name; not the standard portable Bourne-shell built-in (though some shells accept it, it is not POSIX portable). cdir: not a standard command. None of the above: incorrect because cd is correct. Common Pitfalls: Confusing cd with external programs; forgetting that cd with no argument goes to $HOME; assuming chdir works everywhere (it is not portable across all Bourne-like shells). Final Answer: cd

Question 7

Shell globbing — change into a directory whose name starts with the letter ‘‘p’’  In a POSIX shell (bash/sh), which command correctly changes the current directory to a directory whose name begins with the letter p (for example, photos, projects), u…

Accepted Answer

Introduction / Context: Wildcards (globbing) let you match filenames and directory names without typing them fully. Knowing which pattern matches “names starting with p” is a basic shell skill useful for navigation and scripting. Given Data / Assumptions: We are in a POSIX shell (bash/sh) with standard pathname expansion enabled. There exists exactly one target directory whose name starts with p (or you will choose one uniquely). We want a pattern meaning “p followed by zero or more characters”. Concept / Approach: Shell globbing uses special metacharacters. The asterisk matches zero or more arbitrary characters. The question asks for a directory beginning with p, so the pattern is p. The question mark ? matches exactly one character; bracket expressions like [p] match a single literal from the set, not an entire name. Step-by-Step Solution: Decide the needed match: names that start with p and have anything (or nothing) after.Select the wildcard: matches zero or more trailing characters.Combine with cd: run cd p.Ensure the pattern expands to exactly one directory to avoid “too many arguments.” Verification / Alternative check: Use echo p* to preview matches before running cd. If multiple directories match (projects, papers), specify more letters (e.g., cd proj*). Why Other Options Are Wrong: cd p: tries to change into a directory literally named p only. cd p?: matches exactly two characters long names like pa, not general “starts with p”. cd [p]: matches a single character from set {p}; not a full name. None of the above: incorrect because cd p* is valid. Common Pitfalls: Forgetting that globbing is performed by the shell before invoking cd; having multiple matches causes ambiguity; hidden directories (starting with dot) are not matched by p* unless explicitly included. Final Answer: cd p*

Question 8

Bourne shell login initialization — which file sets a user’s environment on login?  In the classic Bourne shell and Bourne-compatible shells, which file in the user’s HOME directory is executed to initialize the environment at login?

Accepted Answer

Introduction / Context: When a user logs into a Unix system using a Bourne-compatible shell, the shell reads certain startup files to set environment variables, PATH, aliases, and other customizations. Recognizing which file is responsible is essential for troubleshooting login behavior and configuring user environments. Given Data / Assumptions: Login shell is Bourne-compatible (sh, ksh, bash in POSIX sh-mode). The file resides in the user’s HOME directory. We are discussing traditional login sequence (not necessarily non-login interactive shells). Concept / Approach: The classic Bourne shell reads $HOME/.profile for login shells. Korn shell also reads it; bash reads ~/.bash_profile or ~/.profile if the former is absent for login shells. Other files like .exrc configure vi, and .mbox is a mailbox file. Step-by-Step Solution: Identify the shell type: Bourne-compatible login shell.Know the initialization order: for a login shell, .profile is sourced.Recognize alternatives: bash-specific files may take precedence, but .profile remains the generic answer.Select .profile as correct. Verification / Alternative check: Run echo $SHELL to identify the shell. For bash, check man bash under INVOCATION; for sh/ksh, consult their manuals. You will see .profile mentioned for login shells. Why Other Options Are Wrong: .exrc: editors (vi/ex) configuration, not shell login. lastlogin: not a standard user startup file. .mbox: mailbox file used by mail clients. None of the above: incorrect because .profile is correct. Common Pitfalls: Confusing .bashrc (non-login interactive) with .profile; forgetting that display managers or modern shells may load different files depending on login type; mixing csh (.login) conventions with Bourne shell behavior. Final Answer: .profile

Question 9

Understanding chmod — mapping symbolic to octal permissions  What is the octal equivalent of the command: chmod ugo+rw note (i.e., give read and write to user, group, and others on the file ‘‘note’’)?

Accepted Answer

Introduction / Context: Unix file permissions can be expressed symbolically (u, g, o with r, w, x) or numerically (octal). Converting between the two is a fundamental skill for system administration and scripting. Given Data / Assumptions: Command is chmod ugo+rw note. Target is a regular file named note. We only add read and write for user, group, and others (no execute bits). Concept / Approach: Octal permission digits represent rwx as bits: r=4, w=2, x=1. For each of user, group, others, sum the bits enabled. With read and write set, value is 4+2=6. Applying to all three classes yields 6 6 6, so the octal is 666. Step-by-Step Solution: Map r to 4, w to 2, x to 1.For u: rw- equals 6.For g: rw- equals 6.For o: rw- equals 6, so overall 666. Verification / Alternative check: Run chmod ugo+rw note then ls -l note: you will see -rw-rw-rw-. Converting each triplet rw- to numbers confirms 6 for each class. Why Other Options Are Wrong: 555: r-x for all; lacks write. 444: read-only; no write or execute. 333: -wx; no read. None of the above: incorrect because 666 is correct. Common Pitfalls: Confusing execute with write; forgetting special modes (setuid/setgid/sticky) which would add a leading octal digit; assuming directories use the same mapping (they do, but execute means “traverse”). Final Answer: chmod 666 note

Question 10

Assigning specific permissions with chmod — rwx for owner, rw for group, x for others (file ‘‘note’’)  Which chmod command sets: owner = read+write+execute, group = read+write, others = execute only?

Accepted Answer

Introduction / Context: Being able to translate a human description of permissions into a chmod command is a daily task. Here we translate “owner rwx, group rw, others x” into octal. Given Data / Assumptions: Owner needs rwx (read, write, execute). Group needs rw- (read and write). Others need --x (execute only). Target file name is note. Concept / Approach: Octal digits encode rwx as r=4, w=2, x=1. Compute each class separately and concatenate the digits. Step-by-Step Solution: Owner: rwx = 4+2+1 = 7.Group: rw- = 4+2 = 6.Others: --x = 1.Result: 761, so command is chmod 761 note. Verification / Alternative check: After running the command, ls -l note should display -rwxrw--x, matching the requirement. This confirms the mapping is correct. Why Other Options Are Wrong: chmod 671 note: gives owner = 6 (no execute), group = 7 (adds execute), others = 1 (correct for others) — mismatches the spec. chmod 167 note: scrambles the order; owner becomes 1 (wrong), group 6, others 7 — incorrect mapping. chmod 4=rwx, g=rw note: invalid syntax; numeric mode must be three digits (or use symbolic modes like u=rwx,g=rw,o=x). None of the above: incorrect because 761 is correct. Common Pitfalls: Mixing up the order owner-group-others; forgetting that execute is needed to run files or traverse directories; using invalid mixed numeric/symbolic syntax. Final Answer: chmod 761 note

Question 11

Octal basics — owner has read and write only  If a file has read and write permissions for the owner (no execute), what is the single octal digit representing the owner’s permissions?

Accepted Answer

Introduction / Context: Unix permissions are often compressed into octal digits: one for owner, one for group, one for others. This question checks whether you can map “read+write only” into its correct octal digit. Given Data / Assumptions: Owner has read (r) and write (w). Owner does not have execute (x). We only need the single digit for the owner, not the full three-digit mode. Concept / Approach: The mapping is r=4, w=2, x=1. Add the bits that are present to get the octal digit. For rw-, compute 4 + 2. Step-by-Step Solution: Assign bit values: r=4, w=2, x=1.Owner has r and w only: 4 + 2 = 6.Therefore, the owner digit is 6.Result can be part of a full mode like 640 (owner=6, group=4, others=0). Verification / Alternative check: Create a file and run chmod u=rw,go=---. ls -l will show -rw-------; converting rw- to octal gives 6 for the owner. Why Other Options Are Wrong: 1: represents execute only. 5: equals r+x (4+1), not rw. 3: equals w+x (2+1), not rw. None of the above: incorrect because 6 is correct. Common Pitfalls: Confusing the bit weights; thinking the digits are decimal instead of octal; forgetting that absence of execute for regular files is common by default. Final Answer: 6

Question 12

Finding your current login identity — classic Unix commands  Which command prints information about the current login (user and terminal) in a traditional Unix environment?

Accepted Answer

Introduction / Context: Unix provides several commands to reveal identity or session information. Distinguishing among them helps when auditing sessions, writing scripts, or troubleshooting access problems. Given Data / Assumptions: The system provides classic who functionality. We want to report the current user and associated terminal session. We are not simply printing the working directory or command path. Concept / Approach: who am i (equivalently who -m on many systems) displays the entry for the current terminal, effectively showing who you are logged in as and on which TTY. Related commands include whoami (prints just the username) and id (UID/GID and groups). The options listed do not include whoami, so the best match is who am i. Step-by-Step Solution: Identify the requirement: current login identity for this session.Choose classic tool: who restricted to current terminal.Use form who am i to output the entry for the current TTY.Confirm output includes username and terminal. Verification / Alternative check: Run who am i and compare with who (shows all logins), whoami (just the username), and id (numeric IDs). You will see the difference clearly. Why Other Options Are Wrong: i /4: not a valid Unix identity command. pwd: prints working directory, not who you are. which: locates a command in your PATH. None of the above: incorrect because who am i fits the requirement. Common Pitfalls: Confusing who am i with whoami; both are useful but return different information. Also, on some minimal systems, who may behave slightly differently; who -m is a common equivalent. Final Answer: who am i

Question 13

Renaming or moving files in Unix — choose the correct command  Which command is used on Unix/Linux to rename a file (and more generally to move a file to a new path or name)?

Accepted Answer

Introduction / Context: File management in Unix relies on a small set of powerful commands. Renaming is not a distinct operation; it is handled by the same command that moves files between paths. Recognizing the correct tool is essential for scripting and daily use. Given Data / Assumptions: We are on a Unix/Linux system using standard coreutils or equivalent. The goal is to change a file’s name (possibly in the same directory). We want the canonical, always-available command. Concept / Approach: The mv command moves files and directories. If the destination is within the same directory but with a different name, the effect is a rename. While some distributions ship a rename utility, its syntax and availability vary and it handles pattern-based mass renames; mv is the portable tool. remove is not a standard command; file deletion uses rm. ren is a DOS/Windows alias, not standard on Unix. Step-by-Step Solution: Pick the universal tool: mv.Rename example: mv oldname.txt newname.txt.Move and rename example: mv oldname.txt docs/newname.txt.Verify with ls that the new name/path exists. Verification / Alternative check: Consult man mv. You will see it supports moving and renaming. Experiment in a test directory to confirm behavior. Why Other Options Are Wrong: rename: not guaranteed to exist or be consistent across systems. remove: not a standard command (use rm to delete, not rename). ren: DOS/Windows syntax; not standard on Unix. None of the above: incorrect because mv is correct. Common Pitfalls: Overwriting existing files without -i; renaming across filesystems may copy then delete; remembering that permissions may restrict renames in directories without write/execute rights. Final Answer: mv

Question 14

Interpreting long listings — what does ‘‘ls -l’’ tell you?  When you run ls -l on Unix/Linux, which of the following information is displayed for each file entry?

Accepted Answer

Introduction / Context: The long listing format (ls -l) is the most common way to inspect filesystem metadata quickly. Being able to read its columns helps you understand permissions, ownership, size, and timestamps at a glance. Given Data / Assumptions: We are using a typical Unix/Linux ls implementation (e.g., GNU coreutils). We want to identify which data ls -l shows by default. We focus on ownership, size, and modification time. Concept / Approach: The output columns include: file type and permissions, link count, owner (user), group, size in bytes, last modification time, and name. Optional flags (-h, -n, --time-style) change formatting but not the presence of core fields. Hence, owner, group, and size/time are all present. Step-by-Step Solution: Run ls -l in any directory.Observe columns: perms, links, owner, group, size, date/time, filename.Confirm that owner and group names appear (or numeric IDs with -n).Confirm size and last modification time are shown. Verification / Alternative check: Use stat filename for a more detailed view; it corroborates the same metadata shown in summarized form by ls -l. Why Other Options Are Wrong: Each single statement (owner, group, size/time) is true individually, but the best overall choice is “All of the above.” None of the above is clearly incorrect because ls -l shows all these fields. Common Pitfalls: Confusing last access time with last modification time; misreading human-readable sizes with -h; overlooking the link count column; forgetting that timezone and format may vary. Final Answer: All of the above

Question 15

vi/vim editor — overstriking text on a whole line (Replace mode)  In the classic vi editor (command mode), which single key starts Replace mode so that your typing overwrites existing text (useful when you want to overstrike an entire line from the …

Accepted Answer

Introduction / Context: vi and its modern descendant vim provide several modes. Knowing how to enter Replace mode allows you to overstrike existing text instead of inserting and shifting it. This is handy when you want to overwrite a whole line quickly from the cursor position. Given Data / Assumptions: Editor is classic vi/vim in command (normal) mode. We want to overstrike characters rather than insert new ones. We need the single-key command to begin Replace mode. Concept / Approach: In vi, pressing R enters Replace mode. Characters you type overwrite existing characters until you press Escape to return to normal mode. This differs from lowercase r, which replaces only a single character. Other keys like u (undo), v (visual mode), and C (change to end of line) serve different purposes and do not perform continuous overstrike. Step-by-Step Solution: Position the cursor at the start of the line (e.g., using 0) or where overstriking should begin.Press R to enter Replace mode; notice the status indicator in vim.Type the new content; each keystroke overwrites existing characters.Press Esc to exit Replace mode when finished. Verification / Alternative check: Experiment in a test file: type some text, press R, then type a different phrase of the same or longer length. You will see characters overwritten rather than inserted; if longer, following text is overwritten as you continue. Why Other Options Are Wrong: v: enters Visual mode to select text; does not overstrike. C: “change to end of line” (equivalent to c$), which deletes then enters insert mode, not overstrike. u: undo last change. None of the above: incorrect because R is correct. Common Pitfalls: Confusing R with r (single-character replace); attempting to overstrike in Insert mode; forgetting to press Esc to leave Replace mode before running other commands. Final Answer: R

Question 16

vi editor set options (Unix/Linux): In the vi editor, which :set option should be enabled so that searches ignore letter case (for example, 'abc' matches 'ABC') when finding patterns?

Accepted Answer

Introduction / Context: The classic vi editor (and its enhanced variants like Vim) supports numerous runtime options toggled via the :set command. One common usability tweak is making searches case-insensitive, so a single pattern can match both uppercase and lowercase text without extra regex tokens. Given Data / Assumptions: The environment is a Unix/Linux shell using vi or Vim-compatible behavior. The question asks specifically for the option that ignores case during search operations. We are comparing among typical :set abbreviations such as ic, ai, sm, and ts. Concept / Approach: In vi/Vim, configuration options have short names. For search behavior, 'ic' stands for 'ignorecase', which makes the search engine treat uppercase and lowercase letters as equivalent. Other listed options control unrelated features like indentation, parenthesis matching, or tab width. Step-by-Step Solution: Identify the option that affects search case sensitivity: 'ignorecase'.Recall the short form used by :set: 'ic' maps to 'ignorecase'.Confirm that enabling it works: :set ic (or :set ignorecase).Test by searching with /pattern and verifying that PA, Pa, and pa all match when 'ic' is enabled. Verification / Alternative check: In Vim, :help ignorecase documents that 'ic' makes all searches case-insensitive unless 'smartcase' is also set and the pattern contains uppercase letters. Running :set ic? shows the current state. This confirms that 'ic' is the appropriate setting. Why Other Options Are Wrong: ai: 'autoindent' controls indentation of new lines, not search behavior. sm: 'showmatch' briefly jumps to matching brackets during insert mode; it does not affect searches. ts: 'tabstop' defines the visual width of a tab character; it is unrelated to search. None of the above: Incorrect because 'ic' is exactly right. Common Pitfalls: Confusing 'ignorecase' (ic) with 'smartcase' (scs). Smartcase refines behavior when uppercase appears in the pattern, but the base switch to ignore case globally is 'ic'. Another pitfall is setting 'ic' and expecting it to affect substitute flags; remember that substitute is driven by the same search engine but can also be influenced by flags like 'c' for confirm. Final Answer: ic

Question 17

POSIX/Unix filenames and validity: Which of the following is an invalid filename on a typical Unix-like system (plain files in a standard directory, not including reserved names)?

Accepted Answer

Introduction / Context: Unix-like systems are permissive about filenames. Knowing what is valid helps avoid needless errors when creating, copying, or scripting across files. Unlike DOS-era systems with strict 8.3 naming, modern Unix supports long names, spaces, and punctuation (with a few caveats). Given Data / Assumptions: The examples are to be interpreted as ordinary filenames within a normal directory. We are not dealing with special device files, reserved DOS names, or shell wildcards that the shell expands unless quoted. No path separators (/) or NUL bytes are present in the names given. Concept / Approach: Unix filenames can contain any byte except the NUL character and the forward slash. Case is significant (TRY and try are different). Spaces and leading dots are allowed, although they may require quoting or escaping at the shell prompt. Step-by-Step Solution: Check 'shutry': letters only, valid.Check 'TRY': uppercase letters are valid; case sensitivity is normal on Unix.Check 'trial': letters only, valid.Check 'my .file': contains a space and a dot; still valid, though quoting may be needed (for example, '"my .file"').Since all listed names are permissible, select 'None of the above'. Verification / Alternative check: On a Unix shell, running touch "my .file" creates the file successfully. ls -l then lists it normally. This demonstrates that spaces and dots are permissible in filenames. Why Other Options Are Wrong: shutry, TRY, trial, my .file: Each is a valid filename under POSIX constraints (no / and no NUL), so none is invalid. Therefore the catch-all correct response is 'None of the above'. Common Pitfalls: Assuming spaces or leading dots are forbidden. Spaces require quoting to avoid word-splitting by the shell, and a leading dot merely marks a file as hidden in many tools. Truly invalid characters are only the forward slash and the NUL byte; other restrictions may come from specific filesystems or tools. Final Answer: None of the above

Question 18

Viewing text in pages on Unix systems: Which command shows a file interactively 24 lines at a time (default page size), allowing forward movement through the content?

Accepted Answer

Introduction / Context: When inspecting long text files in Unix, paging programs prevent content from scrolling off the screen. Different pagers offer varying controls and defaults; knowing the right tool improves productivity during log analysis and documentation review. Given Data / Assumptions: The requirement is to view files 24 lines at a time by default. We are using classic Unix utilities commonly found on System V-derived systems. We only need to identify the correct pager, not its advanced options. Concept / Approach: The pg command is a historical pager that displays text a page at a time, with a default page length of 24 lines. It accepts commands for navigation and can also follow input from pipelines. Other utilities either print without paging or handle printing tasks, not interactive viewing. Step-by-Step Solution: Consider 'pg': a pager that shows text in 24-line pages.Consider 'cat': dumps full content to standard output without paging.Consider 'lp': sends files to the line printer subsystem, not a viewer.Consider '/p': not a standalone Unix command; resembles a DOS switch.Therefore, select 'pg' as the correct answer. Verification / Alternative check: Running pg /etc/services presents the file in pages. Pressing space advances one page; q quits. This matches the requirement of viewing 24 lines at a time by default. Why Other Options Are Wrong: cat: No pagination; unsuitable for large files on a terminal. lp: Sends output to a printer queue, not to the screen. /p: Not a Unix command; that syntax is typical of DOS switches. None of the above: Incorrect because 'pg' fulfills the requirement. Common Pitfalls: Confusing 'pg' with 'more' and 'less'. While 'more' and 'less' are modern alternatives (with different defaults and features), the question’s historical default of 24 lines aligns with 'pg'. In many systems, 'less' is preferred for bidirectional navigation, but the specific command requested here is 'pg'. Final Answer: pg

Question 19

Disk usage summary on Unix/Linux: Which command is used to summarize per-file and per-directory disk space consumption for quick assessment?

Accepted Answer

Introduction / Context: Administrators frequently need to identify which directories or files consume space. Unix provides standard utilities to summarize disk usage efficiently, assisting in cleanup, quota checks, and capacity planning. Given Data / Assumptions: We are in a Unix/Linux environment. The goal is to summarize disk usage by directory and file. Only standard command names are considered; no third-party tools. Concept / Approach: The du command (disk usage) reports the number of blocks or human-readable sizes used by files and directories. Options like -s (summary) and -h (human-readable) are common combinations. Other listed commands are from different ecosystems or serve different purposes. Step-by-Step Solution: Identify the Unix utility for space reporting at the file/directory level: 'du'.Optional flags: 'du -sh ' to summarize top-level items with readable units.Confirm that 'chkdsk' (DOS/Windows) and 'fdisk' (partitioning) are not relevant to usage summarization.Note that 'disk' is not a standard Unix utility for this purpose. Verification / Alternative check: Running du -sh /var/ quickly reveals which subdirectories occupy the most space. This is the canonical approach for Unix-like systems. Why Other Options Are Wrong: chkdsk: DOS/Windows filesystem checking tool, not a Unix usage reporter. fdisk: Partition table editor; unrelated to per-directory usage. disk: Not the standard tool for usage in Unix. None of the above: Incorrect because 'du' is correct. Common Pitfalls: Confusing 'du' with 'df'. df reports filesystem-level free/used space; du drills down into directories and files. For complete analysis, both are useful together. Final Answer: du

Question 20

Printing files on Unix (System V/BSD style): Which command is commonly used to send a file to the system's print spooler for printing?

Accepted Answer

Introduction / Context: Unix printing relies on a spooler that queues jobs. Users submit jobs via commands that differ slightly across Unix flavors. Recognizing the standard submission command helps in scripts and day-to-day operations. Given Data / Assumptions: System V-style printing uses the lp command; BSD uses lpr. We are asked for a generic, widely used Unix command to print a file. Other listed commands resemble DOS terminology or unrelated utilities. Concept / Approach: The lp command submits a print job to the line printer system (System V lineage). Typical usage is lp filename, with options to select destination printers and copies. On BSD-like systems, the counterpart is lpr, but lp remains a correct and common answer in many Unix distributions. Step-by-Step Solution: Assess each option for Unix printing semantics.Select 'lp' because it is the canonical System V print submission command.Confirm that 'print' and 'prn' are DOS-style and 'pg' is a pager.Therefore 'lp' is the suitable answer. Verification / Alternative check: Running lp /etc/hosts returns a job ID if the spooler is configured. The job can be monitored with lpstat. This validates that lp is used for printing. Why Other Options Are Wrong: print, prn: DOS commands/aliases; not standard Unix print submission. pg: Pager for viewing text; not for printing. None of the above: Incorrect because 'lp' is valid. Common Pitfalls: Confusing System V (lp) with BSD (lpr). On some systems, both commands exist and map to the same underlying CUPS interface; still, 'lp' is fully correct for Unix printing. Final Answer: lp

Unix Questions