Linux has inherited much of its design philosophy from Unix, which was first developed at Bell Labs starting in the late 1960s. Back then, there were no personal computers. Computing was done on large mainframes or minicomputers. Computer operating systems were designed for professional, experienced users. Unix, especially, was considered "by programmers, for programmers."

While there have been great strides to broaden the accessibility of Unix-like systems with friendlier user interfaces, the Linux terminal reflects its technical roots. Unlike in modern GUI environments, Linux shells don't try to protect you from yourself. If you want to delete a file or modify it, even an important file, if you have the correct permissions, it will let you go straight ahead, even if it would damage the system.

If you delete a file in the terminal, you can't get it back. It's gone forever, unless you have a backup.

It's also possible to make it so that you can't log in, launch a terminal, or even boot the machine if you aren't careful. You might be able to restore your system from backups if you made them. Or you might be able to fix it by booting into a USB stick. At the worst, you might have to reinstall your OS. A lot of things are fixable in Linux, but it's better to spend time doing things you really want to do instead of fixing your machine.

What Commands Are Dangerous?

You should be wary of running commands that can cause data loss.

The command you should be most careful with is rm, the command that deletes files in the terminal. As I mentioned earlier, when you delete something with rm, it's gone forever. There's no recycle bin or trash can, so you can't undelete something you deleted by mistake, even if you made a typo.

Even worse, the OS can overwrite the physical location of the file on the drive, making recovery impossible. You could shell out for a data recovery service or try to recover it yourself, but the process will likely take a lot more time and/or money than it's worth for a small file, so it's best to use other means when you can.

The other command that can cause major data loss is dd. This command copies bits from one file to the other, but it's been nicknamed "disk destroyer" for a very good reason. One thing that a lot of people mess up is the source and destination locations. If you mix them up, you can say goodbye to whatever was on that device.

You should also be wary of modifying system files. Linux depends on these for a lot of things, like connecting to the internet and booting Linux itself. If you modify something without knowing what you're doing, or even make a typo, you can make it less secure, or worse, even unbootable.

The shell's startup files can also make it impossible to launch a shell if you mess them up. That's something that I learned the hard way.

You can really mess up your system if you don't know what you're doing.

I Run as a Regular User Whenever Possible

The first line of defense against any erroneous commands or editing is running as a regular user. I only run as a regular user as much as I can. The only times I run as root are when I actually do need to make system-wide changes, such as installing new software or making changes to the configuration files. When I need to do that, I run sudo or su, depending on what kind of system I'm using.

The file and user protections will help prevent any undesirable changes. For one thing, having to type "sudo" forces me to think about what I'm doing. I try to avoid making major changes when I'm tired or in a hurry.

I Double-Check Potentially Risky Operations

When I know I'm doing something potentially risky, I slow down and try to think about what I'm doing. If I'm going to delete a file, I examine the command line to make sure it's the right one. If I'm editing a system file, I make sure that I haven't made any typos before I save in the editor and reboot.

These are things that I've learned from experience. I learned to be careful not on a Linux system, but on a DOS/Windows PC from my childhood. I was trying to get some old game that ran in CGA, with the yucky (RGB-based) magenta color scheme, to run in a different palette. I'd seen that I could go to the BIOS setup screen, and I could change system settings. I changed the video card settings. Somehow, I managed to clear all the BIOS settings and then save them. If you know anything about PCs, this is a bad thing. The system didn't know what hardware it had anymore, since this was the pre-plug-and-play era. There were no serious hardware issues, and the system was eventually fixed, but my dad was pretty mad, and I had to play outside!

Since then, my approach to system management is a lot more conservative. I try to avoid making changes to the system unless I absolutely need to. I can understand the urge to customize if you're new to Linux, but a lot of users seem to take an approach of fixing things that aren't broken until they are, and then slump into some forum asking for help.

I Have A Backup Terminal Handy

When I make changes to the shell startup files, such as Bash's .bashrc or morely likely Zsh's .zshrc, I have another terminal handy. I'll test my changes in one terminal by running the source command to read in the changes:

        source .zshrc
    

I then monitor this terminal for any error messages or anything that makes the terminal not run. I'll use the other terminal as a "known good" terminal. I can undo any changes in this terminal window if I have to. This gives me peace of mind, since I use the terminal so frequently.

I Back Up Important Files

One thing that you should do is back up important files, no matter what system you're running.

When I make a change to a system file, I like to make a quick local backup of the known good state with a ".bak" extension:

        
cp example.conf example.conf.bak
    

If I make a mistake and I can still boot into the system, I can just copy it back over:

        
cp example.conf.bak example.conf
    

This will overwrite the modified file with the copy of the original.

Backing up anything you don't want to lose is also a good idea, especially to external media or a network drive.

Rescuing a Broken System

If you do make a mistake, all is not lost. There are some things you can do. If you have backups, you can just restore them and get rid of the offending mistake or put back files you deleted by mistake. The only problem is that you have to commit to making backups.

You can also have bootable media handy, such as a USB key with your Linux install media. A lot of them have tools to run hardware diagnostics. Much of the time, you can mount your Linux hard drive or SSD and make changes from your boot media to restore your system to working order.

If you really broke your system, you can wipe it and reinstall Linux as a last resort. Shown above is the Debian recovery menu in the installation program.

While these are good cures, I've found that prevention is much better. These things are like making disaster plans. You want to avoid needing to use them in the first place, but you'll be glad you had the option.

I've found the best prevention is the message that you get when you run sudo for the first time. One of its admonishments is that you should "think before you type." This is the lesson you should take when using the command line in Linux

---

If you're new to the Linux terminal, it pays to be cautious in the commands you run. With a little foresight, you can avoid disasters that can force you to reinstall your OS.