This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
A command is a sentence with a user and a directory
Every command in a ticket has a user, a working directory, and the exact line. A line that worked in your interactive shell may depend on an alias, a function, or a PATH the next person does not have. Prefer the form that man will describe. If you use a shorthand, say so.
find walks a tree. The path comes first, then the tests, then the action. find /srv/www -type f -name '*.log' is a search. Adding -delete is a different command and does not belong in a search ticket. grep searches the contents of files. The pattern is a regular expression unless you pass -F for a fixed string. Quoting the pattern keeps the shell from eating stars and spaces.
Pipes pass text, not objects. The next command sees lines. If you need a field, cut or awk can take it, and you still check a sample line because a column can move. Do not parse ls. The listing is for a human. find -printf or stat is for a script.
sudo runs a command as another user, usually root, under the rules in sudoers. A ticket that says sudo without the command is incomplete. A script that uses sudo -n will fail closed when a password is required, which is what you want in a job, and it will not magically have permission. The sudoers auditor is a separate guide. This page only asks you to name the command you are allowing.
Find the logs, then grep one host name
The lab search is files under /var/log whose names end in .log, on a host you are allowed to read. The find line is find /var/log -type f -name '*.log'. The quotes keep the shell from expanding the star before find sees it. If you are not root, some files will be skipped. That skip is a permission result, not an empty log.
The grep is grep -F 'edge-01' on a file you named, or grep -R -F 'edge-01' /var/log/app if the ticket says to walk a directory the account may read. -F means the name is literal. -n adds line numbers so the ticket can cite one. A pattern with a dot is a regular expression if you forget -F, and a dot matches any character. Literal first, regex when you meant a regex.
Read the first matches before you send the output anywhere. A log can contain a token a person pasted by mistake. The line you keep in the ticket is the timestamp and the event, not a secret that happened to be on the same line. If the line has a secret, rotate the secret. Do not file it.
The command explainer, the find builder, and the grep builder on this site show the line they will not run. Compare that line to the one in the ticket. Then run it yourself on the path you named.
| You want | Start from | Do not start from |
|---|---|---|
| Files by name | find path -type f -name 'exact*' | ls | grep, which breaks on odd names |
| A literal string in a file | grep -F -n 'string' file | grep string file, if the string has a dot or a star |
| A column from a simple line | awk or cut on a sample you checked | A one-liner you have not run on one real line |
| Disk space by mount | df -hT | A guess from a full filesystem error alone |
A change you can finish
Run the search as the user who will own it later. Keep one matching line and one explanation of what you will do with it. A search that prints ten thousand lines is a search to narrow, not a search to paste into chat.
If the next step changes files, it is a new ticket line with a rollback. find and grep do not get an action flag added in the same breath as the search.
- Write the path, the user, and the question the command answers.
- Quote patterns so the shell does not expand them.
- Run the search and read a sample, including a line that should not match.
- Narrow the path if the output is larger than you will read.
- Keep the line and the command in the ticket.
- Remove any secret from the note and rotate it if it was real.
- Only then write a second command if something must change.
Mistakes that outlive the command
the Linux command page fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.
- find -delete or grep with an in-place edit in a command you called a search.
- An unquoted star, so the shell expands it in the current directory and find never sees the pattern.
- grep without -F on a name that contains a dot, matching more than the host.
- Parsing ls in a script because the columns looked stable on your laptop.
- sudo in front of a command to hide a directory the service account should have been able to read.
- Walking / as root because the file might be anywhere. Name a path.
- Pasting a log line that contains a token into the ticket.
- An alias on your workstation that does not exist on the server, so the ticket's command is not the one you ran.
Decisions to write down before the window
One decision for the Linux command page: The path is specific. /var/log/app or /srv/www, not the whole filesystem, unless the ticket explains why. Patterns are quoted. Fixed strings use grep -F. A regex is labelled as a regex. The user is named. Root is used when the files are root-only, and the sample you keep does not include secrets. Search and change are separate lines. No -delete, no in-place edit, on the search line. The command in the ticket is the command that will run on the host, without an alias. A pipe is used when you need a field, and you checked one input line and one output line. sudo is the command plus the rule, not a habit. The sudoers guide is the audit. Output that is huge gets a narrower path before it gets a scrollback. The explainer's line matches the ticket before anyone presses enter on the host. Rollback of a search is nothing, because a search did not change the host. If you cannot say that, it was not a search. And the working directory is in the ticket when the command uses a relative path. An absolute path does not need one, and you said which it is.
Command checks before the line goes in the ticket
Confirm this before you call the change done: The path in the command is the path in the ticket. The pattern is quoted. grep -F is set if the string is literal. A sample match and a sample non-match were read. No action flag is present on a search. The user who ran it is the user who will run it next time. No secret from the output was copied into the ticket. The command does not depend on an alias. A pipe's field was checked against one real line. Root was not used to avoid fixing a directory mode. The explainer output and the ticket agree. A second person can read the line without asking what the star does. The same line was pasted into the ticket after it ran, not a tidied version that you have not executed. The hostname in the prompt matches the hostname in the ticket for the Linux command page. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for the Linux command page happened, and the next host is not started early. If one of those fails, stop.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar.
- Cheat Sheet: find Command Examples
- Cheat Sheet: tar Command Examples
- How-To: rsync Guide for Admins
- Comparison: scp vs rsync vs sftp
- Explainer: grep, sed and awk Explained
- Explainer: xargs Explained
- Comparison: Hard Links vs Symbolic Links
- How-To: Using dd Safely
- How-To: Process Management in Linux (ps, kill, pkill)
- How-To: Finding Open Files and Ports (lsof, ss)
- Cheat Sheet: Linux Networking Commands Cheat Sheet
- How-To: Configuring Network with Netplan
- How-To: Configuring Network on RHEL (nmcli and keyfiles)
- Cheat Sheet: tmux and screen Cheat Sheet
- How-To: Changing Permissions Recursively the Right Way