"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
_______________________________________________
Bug-fileutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-fileutils
