Situatie
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.
You should be wary of running commands that can cause data loss.
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.
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.
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.
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.
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.
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.
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.
Leave A Comment?