Why Aliasing rm Command is a Bad Practice in Linux

An alias in Unix/Linux is a shortcut that allows you to create custom commands or modify how existing commands behave. By using the alias command, you can abbreviate a long command or add options to commands by default, making them easier or safer to use.

However, you must be cautious when using aliases, especially when they change the behavior of powerful commands like rm, to avoid developing bad habits or encountering unexpected behaviors across different systems.

In this brief tutorial, we will learn why aliasing rm to rm -i is a bad practice with a practical example. We are also going to learn about the best practices and safer alternatives to alias the rm command in Linux.

Table of Contents

Why Some People Aliasing rm to rm -i

When you use the command rm on a Unix/Linux system, it deletes files immediately and permanently. It's a powerful command that must be used carefully to avoid accidentally deleting important files.

Some people create an alias for rm, like alias rm="rm -i", to make it safer. This alias changes the rm command to always ask for confirmation before deleting anything.

Let me show you an example, so you can understand it better.

Example of rm Without Alias:

$ rm important-file.txt

This command will immediately delete important-file.txt without asking if you're sure. It's quick but risky if you make a typo or change your mind.

Example of rm With Alias (rm -i):

$ rm important-file.txt

With the alias, this command now asks, "remove regular file 'important-file.txt'?" You must type y (yes) to delete it or n (no) to cancel. It feels safer because it adds a step to double-check your decision.

Why Aliasing rm command is a Bad Practice

The alias rm='rm -i' is very dangerous because;

Reason 1 - Bad Habits

If you get used to the rm command always asking for confirmation, you might become less careful about double-checking which files you're deleting.

One day, if you use an user account without that alias set, rm might delete files immediately. By the time you realize what's happening, it could be too late.

This habit can also be dangerous on systems without this alias because rm will delete files immediately, without asking any confirmation.

Reason 2 - Inconsistent Behavior

If you use different computers or systems (like a office computer, a server, or a friend's laptop), the rm command might not have the same alias.

This inconsistency can lead to mistakes, where you expect to be asked for confirmation but aren't, and accidentally delete something important.

Reason 3 - Scripting and Automation Issues

Scripts that use rm will also be affected by the alias. If a script expects to delete files without confirmation, the alias can cause it to get stuck waiting for a response. This can break automation and cause confusion.

Learning the Right Habits

Instead of relying on an alias for safety, it's better to practice careful command use. Here are some tips:

• Always double-check the command and the files it will affect before pressing Enter.
• Use the ls command to list files and make sure you're in the right directory.
• For critical deletions, manually type rm -i to get a confirmation prompt just for that instance, rather than making it the default behavior.
• Practice using rm in a safe environment, like a folder with unimportant test files, to build confidence and good habits.

Safer Alternatives to aliasing rm Command

Instead of aliasing the default rm command to rm -i, you can use any one of the following safer alternatives:

1. Using a custom Alias with a different command name
2. Create a safer file deletion script that puts the deleted data in a trash directory
3. Use trash-cli tool
4. Use Filesystem snapshots

1. Create a Custom Alias

If you want to create a custom alias for the rm command, use entirely a different name, for example rmi or rmcli or myrm etc.

For example, I am going to create an alias called rmi.

$ nano ~/.bashrc

Add the following line at the end:

alias rmi='rm -i'

Save the file and close it.

From now, you should use the rmi command for deleting files, instead of the default 'rm'.

$ rmi somefile.txt

You will be prompted if you really want to delete the file.

rm: remove regular file 'somefile.txt'?

Press 'y' to confirm the file deletion or press 'n' to skip it.

Creating a separate alias like alias rmi='rm -i' is indeed a safer and more effective approach than overriding the default behavior of the rm command.

This method allows you to have an interactive deletion option without altering the fundamental behavior of rm, thereby reducing the risk of accidental deletions due to overreliance on the alias.

Benefits of Using alias rmi='rm -i':

Here's why this alternative is beneficial for safer file deletion:

1. Clear Distinction: It keeps a clear distinction between the standard rm command and its interactive version, reducing the chance of reflexively using rm and expecting a confirmation prompt.
2. Reduced Risk on Unfamiliar Systems: If you're working on a system that doesn't have your personalized aliases, you're less likely to accidentally delete files because you won't be in the habit of relying on rm to ask for confirmation.
3. Flexibility: You can choose when to use rmi for safer deletion and rm for quicker, non-interactive deletions, depending on the situation and your level of certainty.

2. Create a Safer File Deletion Script

In the previous example, we created a custom command called 'rmi' that prompts for confirmation before deleting files. Alternatively, you could write a small script that includes logging and moves files to a trash directory for later review or recovery.

2.1. Create the script

Create a text file called rmcli with the following contents in it:

#!/bin/bash
# rmcli: A safer file deletion script

TRASH_DIR="$HOME/.trash"
LOG_FILE="$HOME/.rmcli.log"

# Ensure trash directory exists
mkdir -p "$TRASH_DIR"

# Move files to trash instead of deleting
for file in "$@"; do
    timestamp=$(date  %Y-%m-%d_%H-%M-%S)
    trash_path="$TRASH_DIR/$(basename "$file")_$timestamp"
    mv -v "$file" "$trash_path"
    echo "[$timestamp] $file -> $trash_path" >> "$LOG_FILE"
done

Feel free to modify the script according to your needs, such as changing the trash directory location or log file format. Save the file and close it.

2.2. Make the script executable:

After saving the script, you need to make it executable. This allows you to run it as a command. To do this, use the chmod command:

$ chmod  x rmcli

2.3. Move the Script to a Location in Your PATH:

For convenience, you should move the script to a location in your system's PATH so that you can run it from any directory. A common place for personal scripts is /usr/local/bin:

$ sudo mv rmcli /usr/local/bin

2.4. Using the Script:

Now, you can use the rmcli command just like you would use rm, but with the safety features of your script.

For example:

$ rmcli somefile.txt

This command will move somefile.txt to the trash directory instead of permanently deleting it.

Sample Output:

renamed 'somefile.txt' -> '/home/ostechnix/.trash/somefile.txt_2024-02-28_16-53-59'

You can verify it by listing the contents of ~/.trash directory.

$ ls ~/.trash

2.5. Recover Files:

To recover files, navigate to the trash directory (~/.trash in the example) and move the files back to their original location or elsewhere as needed.

$ cd ~/.trash

$ mv somefile.txt_2024-02-28_16-53-59 ~/somefile.txt

2.6. Logging:

The script logs each "deletion" with a timestamp. Ensure the log file location specified in the script exists or is writable. You can review this log to see what files were moved to the trash.

$ cat $HOME/.rmcli.log
[2024-02-28_16-53-59] somefile.txt -> /home/ostechnix/.trash/somefile.txt_2024-02-28_16-53-59

3. Using trash-cli

The another safer alternative to rm is using a command-line trash can utility like trash-cli, which moves files to a trash directory instead of permanently deleting them. This allows for recovery of files if needed.

To know how to install and use Trash-cli, please check the following link:

Trash-cli : A Commandline Trashcan For Unix-like Systems

4. Use Filesystems that supports Snapshots

Using a file system that supports unlimited snapshots, such as BTRFS (B-tree File System) or ZFS (Zettabyte File System), is an excellent strategy for safeguarding against accidental file deletion or overwriting.

Snapshots are essentially read-only copies of the file system at a specific point in time but are highly efficient in both space and time because they store only the differences from the previous snapshot.

How To Create And Manage Btrfs Snapshots With Snapper In openSUSE

5. Other Safer Practices

1. Verbose Mode: Use the verbose option (-v) with rm or your alias to get a detailed output of what is being deleted. This can help catch mistakes before they happen. For example, alias rmi='rm -i -v'.
2. Scripted Safeguards: For users who frequently delete files in bulk or through scripts, consider writing a wrapper script around rm that includes logging of deleted files or requires explicit confirmation for deletions above a certain threshold (e.g., number of files, file size).
3. Educate and Practice: Regularly educate yourself and others about the implications of command-line operations and practice safe file management habits. This includes double-checking the current directory (pwd), listing files (ls or la) before deletion, and using absolute paths cautiously.

Conclusion

While aliasing rm to rm -i might seem like a good safety measure, it can lead to overconfidence and mistakes in environments where the alias is not set.

By adopting these tips and best practices, you can significantly reduce the risks associated with accidental file deletion with the rm command on Unix/Linux systems.

Related Read:

• Autotrash – A CLI Tool To Automatically Purge Old Trashed Files In Linux
• Delete Files That Have Not Been Accessed For A Given Time On Linux
• An Easy Way to Protect Files From Accidental Deletion In Linux

The above is the detailed content of Why Aliasing rm Command is a Bad Practice in Linux. For more information, please follow other related articles on the PHP Chinese website!