trash script bugs

[Bill Coffman]

"Safe trash script, the replacement for 'rm'" looks like
a fascinating perl script, with some great potential.
Unfortunately, some dim-wit liked it so much that they
decided to use this version 0.2 script, as a major
production feature in Redhat 7.0.  Namely, some unknown
rpm package has replaced /bin/rm with this script.  Redhat's
rpm believs that /bin/rm belongs to the package nameed
"fileutils", but that version of /bin/rm is an executable.
Thus, some package, which I am unable to identify, has
covertly replaced /bin/rm.  This has caused me much pain
and suffering :^(.

I am using perl 5.6.0, which is the latest redhat rpm
file, perl-5.6.0-10a.  Here's a few symptoms that I
noticed.

1.   /bin/rm -i file
     does not prompt the user before deleting.

2.   /bin/rm file1 file2
     only deletes file1.


3.   I have noticed that when I "try" to delete a large
     file, it may take a loonnng time!  This has a tendency
     to break scripts, which try to delete files, and then
     check to see if the file has really been deleted.
     It also has a tendancy to drive me crazy, when I'm
     trying to do system maintenance, and move large files
     around.  I have actually had to resort hacks like
     "perl -e 'unlink @ARGV' <files>"

4.   When booting, I see lots, and lots, of error messages
     like "/bin/rm died at line 90", apparently it couldn't
     create a "dust" file.  This is probably because my /opt
     directory is on a different partition, and it hasn't
     been mounted yet.

5.   It won't let me remove a symbolic link, which points
     to a directory ("can't rm directory").

6.   From looking at the script, it seems like there are
     probably several other errors, like not acknowledging
     the "--" arg to allow you to delete a file starting
     with a dash, not parsing "-?" args correctly.  Also,
     performance problems due to the fact that it calls
     other UNIX utilities, such as, foreach (`date`), not
     to mention, using tar to generate copies of deleteted
     directories.

7.   Worse yet, this can cause security errors, since
     another script may call /bin/rm, thinking that it is
     immune to any PATH corruption, but would not be the
     case, since you are calling these routines without
     the full path.

8.   There can also be other startup problems.  Suppose
     I have a minimal installation, without a /usr
     directory, or maybe it is not mounted yet.  The point
     is, that I should have anything in /bin, like /bin/rm
     available to me, without having to have /bin/usr
     available first, like /usr/bin/perl.


It's not that I think this script is a bad idea.  It's
just that I believe it should coexist with the tried
and proven, compiled, /bin/rm.  I suppose that once this
script has been fully tested, and I mean fully, then
you might consider removing all external calls, and
translating it into C (via B::CC), and compiling it,
and statically linking it, so that it will not be
dependent on Perl.

If you have any leads on who may have made this script
replace /bin/rm, I'd appreciate it.  I will try to track
it down, and report it to redhat.

Thanks,
Bill Coffman