TCLUG Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TCLUG:2572] I think this works!




On Sat, Dec 05, 1998 at 05:15:50PM -0600, Christopher Palmer wrote:
> On Sat, 5 Dec 1998, Ben Luey wrote:
> 
> > I think my perl script is now ready to replace rm. By copying the file(s)
> > and then deleting them, I don't have to bother with all the syntax
> > changing with using mv. Also perl deals with quotes used in filenames
> > ("my long doc name.wpd" very well. If someone find any problems with the
> > script (or reason not to rename rm and use this as rm and then cron a real
> > delete of /home/delete) please e-mail me. 
> 
> It's a good script. I think by making some (perhaps unwarranted)
> assumptions about your user's powers (i.e., it's a regular user who can
> only mess with things in his home directory), you can do the following to
> make the script more efficient:
> 
> 1. $DELETEDIR = "$ENV{'HOME'}/.Trash" (I like for the trash can to be
> hidden.)

Definately a better location.

> 
> 2. Change the cp-ing to mv-ing (since there's no chance we could be
> crossing paritions) and don't do the 'rm' step ('mv' precludes it). This
> is much more efficient than copying and removing.

That's not good assumption.  Even if in this particular case it may
be valid, going the extra foot here is worth the effort so the script
can be reused on a different system.

> 
> 3. Yes, change the user's .aliases file (or whatever file you keep your
> aliases in) to have 'rm' point to this script. You could also add an alias
> ('mtTrash' or some such) that does 'rm -rf ~/.Trash/*'.

I'd go against naming a script like this 'rm' or even aliasing it unless 
it does exactly what rm does, in terms of features.  Like, -r, -f, -i, etc.
I guess for yourself it would be ok, but if you teach anyone else to use
it that doesn't know Linux very well they may get confused later on when
someone tells them in order to get rid of that dir type "rm -rf foo".

A better solution would be to provide 'nrm' and alias rm to rm -i.

> 
> This isn't the kind of thing I would ever do as root, for security reasons
> among others, so the test to check if the user is root can go (unless you
> want to make it exit safely if the user is root).

As long as it's not setuid root, in root's normal path, and the script is 
only writable by root, then what are the security reasons?

As a side note, in order to get the real username and home directory of the 
process, do something like this:

@pwinfo = getpwuid($<);
$user = $pwinfo[0];
$homedir = $pwinfo[7];

It's more reliable than environment variables like $LOGNAME, $USER, and
$HOME.  It is quite easy (with sudo for example) to be root with these 
set incorrectly.

If 'cp' is used, be *very* careful before using 'rm' to get rid of the
file.  Ironically, by using this script you increase the chance it will
fail (due to lack of disk space), so make sure it handles that situation
well by checking the status of the command after it completes.

-Shawn

--
Shawn T. Amundson               
amundson@gimp.org               http://www.gimp.org/~amundson

"The assumption that the universe looks the same in every
 direction is clearly not true in reality." - Stephen Hawking