In this article
Before you start
Why interviewers ask this
Unix-like systems, the family that includes Linux, run about 92% of the websites whose operating system is known (W3Techs, as of 24 October 2026), so a question about commands is a question about whether you can work on the machine when something breaks. It arrives as "how would you find which pages are failing in this log?" or "what does chmod do?" in a DevOps, backend or site-reliability round, and as a warm-up in many coding rounds.
A weak answer lists command names. A strong answer says what each command takes as input, what it prints, and how two of them connect, then names the one that is dangerous. This page teaches the pieces from scratch and ends with an answer you can say aloud. The wider topic is mapped in the DevOps and cloud interview guide.
Linux commands from first principles
- Shell
- A shell is a program that reads the commands you type, starts the programs they name and prints the results, so that you can control a computer with text instead of a mouse.
- Linux command
- A Linux command is a line of text made of a program name, optional settings and the things to act on, which the shell runs to do one small job such as listing files or counting lines.
- Pipe
- A pipe is the vertical-bar symbol that connects the output of one command to the input of the next, so that small commands can be chained into a larger job.
- File permission
- A file permission is a setting that says who may read, write or run a file, shown as a pattern of letters such as rwxr--r--.
In plain words
Typing a command is like writing a note to a literal assistant. It does exactly what the note says. It does not ask whether you are sure. The assistant here is the shell, a program defined in the Bash manual as a command language interpreter. The analogy breaks in one place: a real assistant would stop at a dangerous note, and the shell often will not.
Behind the shell sits the kernel. The kernel is the core of the operating system, the part that controls the disk, memory and processes. A command travels from your keyboard through the shell and a program to the kernel. In one precise sentence: a command names a program, adjusts it with options, and points it at arguments.
Text description of the diagram
- The shell reads the commands you type and starts the programs they name.
- A command travels from your keyboard through the shell and a program to the kernel.
Step 1: Read the shape of a command
A command has three parts: the program name, options that change how it behaves, and arguments that say what to act on. In ls -l /tmp, ls is the program, -l is an option that asks for the long listing, and /tmp is the argument. An argument is the thing a command acts on, such as a file or a directory. Options usually start with a dash. The Linux manual pages are the reference for each program, and the Linux man-pages project numbers them by section, with section 1 for commands you run from a shell (version 6.19, February 2026). On a server, man ls opens the page for ls. You now know the grammar every later command follows.
Step 2: Move around with pwd, ls and cd
The three commands for finding your way are pwd, ls and cd. A directory is a folder, and the shell always works from one of them, the current directory. The command pwd prints where you are; in our run, cd /tmp && pwd printed /tmp. The command ls lists what is in a directory, and ls -l adds sizes, owners and permissions. The command cd changes the current directory: cd /tmp/work moves into it, cd .. moves up one level, and cd alone returns to your home. Paths that start with a slash begin at the root of the whole system; paths that do not begin at where you are. After this step you can reach any file.
Step 3: Change files, and why rm asks nothing
Four commands create, copy, move and delete: mkdir makes a directory, cp copies a file, mv moves or renames it, and rm removes it. In our run, cp access.log backup.log followed by mv backup.log old.log left two files, and rm old.log left one.1 The danger is rm. The Coreutils manual says rm asks only when a file is unwritable or when you add -i or -I (Coreutils 9.12 manual, rm). For an ordinary file you own, it asks nothing.
The reason it asks nothing is that rm trusts whoever typed the line. It has no Trash folder to move files into and no undo command; the file name is simply removed. The same manual adds that the contents are "usually possible to recover" with forensic tools, which is why it points to shred for sensitive files; for you there is no command that brings the file back, so treat it as gone.
The error that costs people their files is a stray space, which turns one target into two. In our run, rm -r logs/ * (-r removes a directory and everything inside it) inside a folder holding logs and src left 0 entries where there had been 2: the space after logs/ made *, everything in the folder, a second target.
The Coreutils rm, the version on most Linux servers, does refuse to remove / itself by default (--preserve-root, per the same manual), so a typo like rm -r build / removes only build; the guard does not cover your home folder or a *. Read the line first, and use rm -i when unsure: answering n kept the file in our run.
Step 4: Look inside files with head, wc and grep
Three commands answer most "what is in this file?" questions: head prints the first lines, wc -l counts lines, and grep prints the lines that match a pattern. The Portable Operating System Interface (POSIX) standard, which fixes how these tools behave across systems, says that grep searches the input files, selecting lines matching one or more patterns (POSIX.1-2024, grep). It also defines the options used here: -c counts matching lines, -n numbers the lines, -v selects lines that do not match, and -i ignores case. In our 12-line log, wc -l printed 12 and grep -c ' 500' printed 5. Counting first tells you whether to read the output at all.
Step 5: Combine commands with pipes and redirection
A pipe sends the output of one command into the next, and redirection sends it to a file. The Bash manual defines a pipeline as a sequence of commands separated by the vertical bar. Each command does one small job. The symbol > writes output to a file, replacing it, and >> appends; 2> sends only the error messages, so ls missing.txt 2> err.txt put one error line in err.txt and printed nothing on screen.
In our run, echo one > n.txt followed by echo two >> n.txt left a file of 2 lines. The pattern to remember is filter, extract, sort, count. The command grep keeps the lines you want, cut takes one column, sort groups equal lines, and uniq -c counts them. That four-part pattern, written as five commands because sort appears twice, solves most log questions in one line.
Step 6: Control access with chmod
The command chmod changes who may read, write or run a file. The first ten characters of ls -l show the permissions: the first is the file type, and the next nine are three sets of read, write and execute for the owner, the group and everyone else. In our run a new script showed -rw-r--r--, so it could not be started as ./hi.sh (that needs the execute permission, although sh hi.sh needs only read permission); after chmod u+x hi.sh it showed -rwxr--r-- and ./hi.sh printed hello. The u+x means: for the user who owns it, add execute.
Permissions can also be written as three octal digits: chmod 755 gave -rwxr-xr-x and chmod 644 gave -rw-r--r-- in our run, where each digit adds read 4, write 2 and execute 1 (so 7 is read, write and execute, 6 is read and write, 5 is read and execute, and 4 is read only), and the three digits are owner, group and others. Permissions are why a program can fail with "Permission denied" even when the file exists. You now have the dozen: pwd, ls, cd, mkdir, cp, mv, rm, head, wc, grep, sort with uniq, and chmod.
Step-by-step description
- Program, options, arguments.
- pwd, ls and cd find your way.
- rm trusts you: no Trash, no undo.
- head, wc and grep look inside.
- A pipe chains commands.
- chmod sets who may run a file.
- A command has a program name, options and arguments.
- The commands pwd, ls and cd find your way.
- The commands mkdir, cp, mv and rm change files.
- The commands head, wc and grep look inside files.
- A pipe sends the output of one command into the next.
- The command chmod sets who may run a file.
Ten more for a live server
The commands below add to the dozen and cover the file-and-process questions a DevOps round tends to ask. Each is documented in section 1 of the Linux man-pages. Read the table by question: a DevOps interviewer usually asks which file, which process or which disk, and each row maps one of those questions to a command you can name and explain in a sentence.
| Command | What it answers | Typical use |
|---|---|---|
cat file, less file | what is in the file | less pages a long file; press q to quit |
tail -n 2 access.log | the last lines | printed the last 2 lines in our run |
tail -f access.log | new lines as they arrive | watch a log live; stop with Ctrl+C |
find . -name '*.log' | where a file is | printed ./access.log in our run |
ps, kill <pid> | which processes run, and stop one | kill asks the process to end |
df -h, du -sh * | how full the disk is, and which folder is big | df shows filesystems, du sums folders |
sudo <command> | run one command as an administrator | only for the one command that needs it |
chown user file | who owns the file | pairs with chmod for access |
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
Take a web server log of 12 lines, each with an Internet Protocol (IP) address, the request method, the page and the status code (illustrative data, written by the script). The question is which pages return errors and how often. All outputs below come from a real run in a Linux container.1
| Command | What it does | Output on the 12-line log |
|---|---|---|
wc -l access.log | counts lines | 12 |
grep -c ' 500' access.log | counts lines with status 500 | 5 |
grep -vc ' 200' access.log | counts lines that are not 200 | 6 |
grep ' 500' access.log | cut -d' ' -f3 | sort | uniq -c | sort -rn | lists the failing pages with counts | 3 /cart, 2 /pay |
grep ' 500' access.log | cut -d' ' -f1 | sort -u | wc -l | counts distinct callers who saw an error | 4 |
The pipeline reads left to right, and the status 500 is illustrative data like the rest. The grep keeps the five status-500 lines. The cut takes the third column, the page. The sort puts equal pages next to each other, which uniq -c needs, and the last sort -rn puts the biggest count first. The result: /cart three times and /pay twice. The sixth non-200 line is a 404, which the status 500 filter correctly leaves out.
Text description of the diagram
- One pipeline of five commands ranks the failing pages: /cart failed 3 times and /pay 2 times out of 5 server errors.
- The command grep keeps the lines you want, cut takes one column, sort groups equal lines, and uniq -c counts them.
What if the log is in the standard combined format
Real web servers often write the common "combined" layout, where the status code is field 9 and the page is field 7 when split on spaces, and the byte size comes after the status.
In a second 6-line log (illustrative data, written by the script), grep -c ' 500' printed 3, but only 2 requests were server errors: one successful request happened to be 500 bytes long. Piping grep ' 500' | cut -d' ' -f7 | sort | uniq -c | sort -rn then listed /pay, /home and /cart once each, and /home is wrong. The fix is to anchor the match to the status field, which follows the closing quote of the request, so the byte size cannot match:
grep '" 500 ' clf.log | cut -d' ' -f7 | sort | uniq -c | sort -rnThat listed /pay and /cart once each. awk can also test field 9 directly. The lesson for the interview is to say which field holds the status before you match on it.
Trade-offs and edge cases
Two edge cases matter in interviews. First, commands differ slightly between systems. Our run used BusyBox, a compact set of tools common in containers, and the flags above are standard enough to behave the same with the Coreutils tools and the grep program that most Linux servers use; the Coreutils tools are documented in the Coreutils manual (version 9.12).
A Mac ships different versions of the same programs, so a flag that works on a Linux server can fail on a Mac, and the manual page of the machine in front of you is the authority. Second, a pipeline hides failures in the middle: by default the result of the whole line is that of its last command, so test each stage as you build it, starting with the first.
A third trade-off is safety against speed. Adding -i to rm, cp and mv asks before overwriting (cp, mv) or removing (rm), which costs a keystroke and saves a file. For work on servers, the deployment strategies guide shows why careful, reversible changes beat fast ones.
How to answer it in an interview
A service is returning errors. How would you use the command line to find out which pages fail?
I would look at the access log with grep to keep only the error lines, take the page column with cut, sort it so equal pages sit together, count them with uniq -c, and sort the counts in descending order. That gives a ranked list in one pipeline. Before I trust it, I would check the line count with wc -l and run the first stage alone. If I needed to change a file or restart something, I would copy the file first, because rm and mv do not ask for confirmation.
The spoken structure is: filter, extract, group, count, then the safety habit. If the interviewer asks what changes for a live log, say that tail -f access.log | grep --line-buffered ' 500' follows new lines, and that when the filtered stream feeds another command, as in tail -f access.log | grep --line-buffered ' 500' | cut -d' ' -f3, --line-buffered makes grep pass each match on at once instead of waiting for a full block.
Common mistakes
"The shell asks before deleting." (wrong) For an ordinary file you own, rm prints nothing and asks nothing. (right) "I check the line, and use rm -i when unsure."
"uniq counts duplicates anywhere in the file." (wrong) It only compares neighbouring lines, so unsorted input gives wrong counts. (right) "I sort first, then count with uniq -c."
"A file I can see is a file I can run." (wrong) ./hi.sh needs the execute permission, though sh hi.sh needs only read. (right) "I check ls -l and add u+x with chmod when it is a script I wrote."
"> and >> are the same." (wrong) The single arrow replaces the file's contents. (right) "> replaces, >> appends."
Follow-up questions
How do I find out what a command does?
Use man <command> to open its manual page; section 1 of the manual pages covers commands you run from a shell, as the Linux man-pages project documents. Many programs also print a short summary with --help.
Which Linux commands are asked in a DevOps interview?
Expect file navigation, text search with grep, pipes, permissions, and process and disk inspection (ps, kill, df -h, du -sh), as in the table above. Practise explaining a pipeline stage by stage, as in the worked example; the coding interview guide and how loops work show where such questions sit, and the system design guide covers the larger picture.
What are the Linux commands for DevOps interview questions?
Start with the dozen in the six steps, then add cat, less, tail -f, find, ps, kill, df -h, du -sh, sudo and chown. For each, be ready to say what it prints and one way it can go wrong.
What are common Linux interview questions?
The usual ones are what a command does, how to combine two commands, how to read file permissions such as 755 (an illustrative mode), and how to find a failing page in a log. All four are worked on this page.
What if the log is in the standard combined format?
Then the status is field 9 and the page is field 7, and grep ' 500' can match the byte-size field. Anchor the match on the closing quote, as in the worked example above, or test field 9 with awk.
How would you watch a log live, or find out why the disk is full?
For a live log use tail -f access.log, adding | grep --line-buffered pattern to filter it before another command (on a terminal alone, plain grep already prints each match at once). For a full disk run df -h to find the full filesystem, then du -sh * inside it to find the largest folder, and repeat one level down.
- A command is a program name, options and arguments, run by a shell.
pwd,lsandcdfind your way;mkdir,cp,mvandrmchange files, and one stray space, as inrm -r logs/ *, makes everything in the folder a second target.grep,headandwclook inside files; the pipe chains them.- A five-command pipeline ranked failing pages in a 12-line log: /cart 3, /pay 2.
chmod u+xlets the owner start a script as./name.
Sources
- Usage statistics and market shares of operating systems for websites — W3Techs, 24 Oct 2026
- Bash Reference Manual, edition 5.3 — GNU Project (Free Software Foundation), 18 May 2025
- GNU Coreutils manual, version 9.12: rm invocation — GNU Project (Free Software Foundation), 24 Oct 2026
- grep (The Open Group Base Specifications Issue 8, IEEE Std 1003.1-2024) — The Open Group, 1 Jun 2024
- man-pages(7): Linux man-pages 6.19 — Linux man-pages project, 8 Feb 2026
