Before I got obsessed with distro-hopping, I was terrified of the Linux terminal. Since I’d been a Windows user since my early childhood, running long commands inside a CLI environment felt like a scary proposition. Luckily, my experiments with Raspberry Pi OS (Raspbian Buster, as it was called back then) helped me get over my fear of the terminal pretty quickly. While I still wouldn’t call myself a Linux grandmaster even after tinkering with FOSS distros for eight years, I’ve picked up quite a few tricks that make my CLI tasks a lot easier.

Reusing old commands

No need to type long commands multiple times

The only thing worse than manually typing a chain of commands is doing so time and again. Perhaps I need to run the same command a handful of times. Or maybe I fat-fingered an input and ended up having to type the same command again. Either way, typing multiple lines of code gets really aggravating, especially in CLI distros where I can’t just SSH into the terminal and paste commands from another machine.

Luckily for my sanity, Linux includes a handful of ways to re-run old commands. The !! operator, for example, brings the previously executed command to the shell, and since it works even with the sudo keyword, it’s quite handy when I need to repeat commands with root privileges. Meanwhile, the !$ operator only brings the argument from the last command, which is useful when I have to run the same argument with a different command. When I’ve got a series of commands I need to execute again, I browse them using the history keyword. As if that’s not enough, the Ctrl+R key combination lets me recursively search the terminal for old commands.

Checking the help pages of new tools with tldr

And running man when I need detailed information

Although I’ve spent a long time with Linux utilities, I need to consult the manuals and help pages for new packages – especially if they don’t have a graphical interface and rely on terminal commands. The man keyword is a great way to browse the help pages of most packages, but reading entire sections of documentation can get rather cumbersome at times.

That’s where the tldr package comes in handy. Rather than displaying long strings of text about a particular tool, tldr (or too long, didn’t read, as most netizens will identify it) summarizes the essential arguments and flags accepted by it. While I use man for extremely complex tools, tldr is perfect for checking the important commands for an app in a neat format.

Combining commands

Or piping them, depending on my needs

When I need to run too many commands at once, I resort to combining them using certain operators. For example, the semicolon (;) operator lets me add multiple commands to a terminal line and execute them in a sequential manner. The semicolon operator doesn’t care whether a command in the sequence fails or succeeds, so I switch to its && sibling when I want successive inputs to run only when the previous one is executed successfully.

On the flip side, the || operator executes subsequent commands when the previous one in the chain ends up failing – and it’s pretty handy for troubleshooting. Then there’s piping, which lets me use the output of one command as the input for another, with the | operator serving as the intermediary linking them together.

Running lsof for troubleshooting

Easy way to find network sockets and PIDs of malfunctioning processes

Even when you’re using something as stable as Debian, it’s easy to encounter faulty processes and broken packages in Linux distros. Sometimes, it could be a set of services preventing a drive from unmounting. Likewise, you could run into port conflicts, where multiple apps contend for a specific network socket.

Since many error logs fail to state the process IDs of conflicting services, I typically use lsof to track their essential stats, including PIDs, network sockets, and file locations. This may sound like a weird use case, but I often run lsof to check if a port number is already in use before using it for a container.

Keeping my chmod commands in check

After all, chmod 777 presents way too many security risks

Linux permissions can be a royal pain to manage, especially when you’re coming from Windows or macOS. In my days as a fledgling Linux user, I’d typically run chmod 777 on all scripts, files, and folders that gave me trouble when I tried to access them. My reasoning was that since I was the only user on the system, it shouldn’t matter if I had full read and write permissions to my files.

But as I learned more about Linux, I realized how flawed my reasoning really was. Sure, I wouldn’t encounter permission issues with chmod 777, but it would also make it easy for malicious code to deal damage to my system. But more than anything else, it would also expose important system files to the biggest threat to my Linux machine – my gremlin brain. While it’s still not fully secure, chmod 755 (or even 555) is way better for normal services, as it stops me from accidentally overwriting essential files during my tinkering experiments.

Relying on cron scripts for automation

I still need to use cron expression evaluators, though

Between regular backups, clearing cache folders, and checking the operational status of services every few minutes, there are tons of use cases where automation-centric apps come in handy. Better yet, Linux systems support job scheduling via cron scripts, which let me specify the exact date, time, and frequency at which my maintenance task needs to be run.

The only caveat is that cron syntax can be a bit challenging – to the point where I still need to use cron expression evaluators to double-check whether my script executes at the precise interval I want it to.

Some more tips to level up your Linux terminal game

If you’re prone to fat-fingering your Linux commands, the caret operator offers an easy way to fix faulty expressions. All you have to do is use the ^typo^correct-expression syntax to quickly correct the incorrect parameters in previously-run commands. Then there’s the chattr command that, when used with a file, makes it immutable and prevents users from tampering with its contents. Finally, you can use the alias keyword to assign short phrases to frequently-used commands.

👁 Running a Nextcloud container on NixOS
Running everything on Linux as root is a bad idea: Here's why, and what to do instead

Running all commands as the root user may simplify things, but you'll want to avoid doing that