UNIX for Advanced & Expert Users

I read this article as a way to do a non-permanent of something.

I saw 2 problems. The first that my rm is located at /bin/rm. I would assume I would change the location to /bin/rm. The second my rm is a executable file and not a text file. So will replacing my rm file with the shellscript below work? I would think they would need to be the same type of files.

Code:

mv /usr/bin/rm /usr/bin/rm.bak

Code:

#!/bin/bash

mkdir ~/.Trash &> /dev/null

while [ ! -z "$1" ]; do
    mv "$1" ~/.Trash/
    shift
done

Linux Forums - View Single Post - is it not possible to recover files deleted using rm

Has anyone ever done something like this? Would doing this as a alias be easier. One my friends I talked to said it would be easier and safer to do this as a alias. What does everyone think?

No. No.
Do not replace anything in /bin. Plus /bin is a link to /usr/bin. You will break zillions of things you had no idea about. So do not do that. The system could fail on shutdown or reboot due to a problem in your code. Then you have a dead box. Or a doorstop if you need one.

Create an alias in /etc/profile

Code:

if [ $(group -g) -gt 99 ] ; then
  alias rm=/usr/local/bin/rm
fi

Put your code in /usr/local/bin, this will prevent system users from using the altered rm.
/usr/local/bin is meant for this kind of thing - non-standard applications available to all users. If you put other command utilities into /usr/local/bin, add it that directory to your PATH variable.

Better yet, don't change the meaning of "rm" at all... "rm" should do what "rm" does: remove files from the directory tree structure. If you want a user-friendly "trash" command you should call it something else. Benefits:

I mentioned various "rm" options your script doesn't handle: basically, that would be "--recursive" (-r) and "--force" (-f). You could handle these in the "trash" script but things quickly get more complicated. (You can "force" move, but to move recursively across filesystems you have to copy recursively and then remove the source... And then you have to worry about whether you're correctly handling cases where the copy succeeded but the remove failed for one or more files...)

IIRC the trash system on Mac OS X avoids the cross-filesystem issue by creating a trash bin on each filesystem, so that would be another possibility. But it seems to me that to do all this right is not entirely a trivial problem.

Yes, replacing rm is a severely bad idea. Lots of things use rm and unless you perfectly emulate every possible option rm has you'll probably break something important. You might also get your fancy undelete folder rapidly filling with thousands of useless temporary files that really should have been rm-ed.

What I've seen done sometimes is:

Code:

alias "rm=myfancybackupscript.sh"

...in a user's profile.

This has the advantage that myfancybackupscript.sh will be only ever be used in interactive shells. Never in scripts, never in cron jobs, never in system utilities, never in anything built around the real rm -- it only gets run when a human types rm .... It also means no broad changes are made to your system. It also means people can still get the real RM if they want it, by calling it as /bin/rm.