I’m looking for Linux commands that can simplify daily tasks and improve productivity. Which command made the biggest difference in your workflow, and how do you use it?
The trailing slash matters more than people expect with rsync, so check the paths before running it. rsync source/ backup/ copies the contents of source, while rsync source backup/ creates a source directory inside the destination.
I’d pick rsync because it replaces a lot of awkward copy, backup, and synchronization commands. A typical first pass is:
rsync -avh --dry-run ~/Documents/ /mnt/backup/Documents/
If the preview looks right, remove --dry-run. It works over SSH too, so the same basic command can copy files to another machine.
The main warning is --delete. It’s useful for making an exact mirror, but it will remove destination files that aren’t present in the source. Always pair it with --dry-run first.
For daily terminal work, rsync is too specialized to be my pick. cd - is the tiny command that saves constant typing: it jumps back to your previous directory, so you can bounce between a project folder and logs, configs, or build output by running it repeatedly.
Try this in a directory where you have a lot of files:
find. -type f -iname '*.log'
For me, find is the command that best fills the gap between “I know this file exists somewhere” and “I know exactly where it is.” rsync is useful once the source and destination are clear, and cd - is handy when you already know where you’re going. find helps when neither of those things is true.
The syntax confused me at first because it reads differently from most commands. Breaking it apart made it easier:
.means start in the current directory-type flimits the results to files-inamematches a name without caring about uppercase or lowercase'*.log'is quoted so the shell does not expand the wildcard beforefindsees it
It gets much more useful once you search by something other than a filename. For example:
find ~/Downloads -type f -size +500M
That shows files larger than 500 MB. Or:
find. -type f -mtime +30
That finds files last modified more than 30 days ago. These are simple commands, but they make cleaning old project folders and crowded download directories less guessy.
The bigger step is letting find run another command on each result. This searches configuration files for a particular word:
find. -type f -name '*.conf' -exec grep -nH 'listen' {} +
The {} stands for the files that were found. The + passes multiple files to grep at once, which is generally more efficient than starting a separate process for every file.
My beginner warning would be to stay away from -delete until the search expression produces exactly what you expect. Print the matches first:
find./cache -type f -name '*.tmp' -print
Only after checking that output should -print become -delete. That is the same basic habit @binarylynx_10 mentioned with rsync --dry-run: separate “show me what this selects” from “actually change something.” find looks like a search command, but with the wrong action attached it can become a very effective deletion command.
Finding a file versus finding a command you already ran are two different problems, and the thread only covers the first. For the second, Ctrl+R searching your shell history saved me way more typing than cd - ever did. find is great when the file is lost, but half the time I’m just hunting for a command I typed last week.
If you rarely work over SSH, tmux may feel like extra ceremony rather than an upgrade. For remote work, though, it solves a bigger problem than saving a few keystrokes: your shell session survives a dropped connection.
Run tmux, start a build or log monitor, then detach with Ctrl+B followed by D. Later, reconnect and use tmux attach to return to the same session. Compare that with nohup, which keeps a process running but does not restore the whole interactive terminal.
It can split a terminal into panes and manage several sessions, but that overlaps with features in modern terminal emulators. Persistence is the real advantage. A useful habit is naming sessions:
tmux new -s project
Then restore the specific session with:
tmux attach -t project
Ctrl+R, find, and cd - make individual tasks faster. tmux changes how you organize ongoing work. The downside is its key combinations are awkward until they become familiar, so I would learn detach, attach, and session naming before touching a large configuration file.
If you bounce among more than two directories, cd - stops being clever pretty quickly. It only remembers the previous location, which is perfect until your “quick check” involves a project directory, a log directory, a config directory, and wherever the build dumped its latest complaint.
My pick is pushd. It changes directories while keeping the old locations on a stack:
pushd ~/projects/app
pushd /var/log
pushd /etc/nginx
Run dirs -v to see the stack. Then popd removes the current entry and returns you to the previous directory. You can keep peeling back through your working locations instead of repeatedly typing paths or holding a small directory map in your head like that is a reasonable use of memory.
This is basically the expanded version of what @codeminer9255 likes about cd -. In Bash, running pushd with no path swaps the top two stack entries, so it can do the same back-and-forth trick. pushd +2 can jump to a numbered entry shown by dirs -v, though I would check the stack before trusting myself to remember which number belongs to which directory.
The catch is that the stack belongs to that shell session. Close the terminal and it is gone, and separate terminals have separate stacks. That makes it less useful than tmux for persistent remote work, but for ordinary local navigation it removes a surprising amount of path typing without installing anything or turning the shell configuration into a weekend renovation project.
A faster search command will not matter much in a small home directory, but inside a source tree I’d pick rg (ripgrep). It covers the common case of “find this text somewhere under here” without building a long find... -exec grep expression.
From a project directory:
rg 'listen'
That recursively searches files below the current directory and prints matching lines with filenames. A few useful variations:
rg -n -i 'timeout|retry'
rg 'TODO' src tests
rg --files -g '*.conf'
The last command lists matching files rather than searching their contents. That makes it handy for feeding filenames into another command, although filenames with spaces still deserve some thought before piping them around carelessly.
There is a catch that causes real confusion: rg normally respects ignore files such as .gitignore, and it skips hidden files. That behavior is usually exactly what you want in a repository, but it can make a file seem missing. Use rg --hidden when dotfiles matter, or rg --no-ignore when you intentionally want ignored build output and dependencies included. Searching all of node_modules is a good way to remember why those defaults exist.
I still agree with @binaryninja2540 that learning find pays off because it can select files by age, size, permissions, and other metadata. For plain text searching, though, rg is less ceremony and harder to get wrong. Small correction to those earlier examples as well: there must be a space after find, so it is find., not find..