[gentoo-dev] Re: rm tragedies: was how to clean the "/tmp" dir

[Eamon Caddigan]

Josh Glover <jmglov@g.o> wrote:
> Quoth Eamon Caddigan (Sun 2004-05-30 03:07:15PM +0000):
>> marduk <marduk@g.o> wrote:
>>
>> > Don't change rm's default behavior.  There is nothing wrong with rm.
>> > There are many people who have for years (decades?) used rm and expect
>> > it to work a certain way, i.e. the Unix way, which is to (wrongly?)
>> > assume the user knows what she is doing and to quietly exit
>> > successfully.  If you must have new behavior, have a new command, say
>> > gentoorm. Or if you must mess with rm, make sure by default it uses
>> > traditional Unix behavior unless you pass it
>> > --some-nonstandard-option-that-otherwise-breaks-rm.  But please don't
>> > change the way most people expect rm to work.
>>
>> Argumentum ad antiquitam. I'm aware of many good arguments for keeping
>> 'rm' the way it is, but "because it's always been that way" isn't the
>> strongest. :)
>
> Sure it is. Have you noticed that the behaviour of basic Unix commands
> (cp, rm, mv, echo, cat, grep, sed... and so on, almost ad nauseum) has
> not changed since the days of yore?

Taking your example, 'echo' is often implemented as a shell built-in,
and it behaves *very* differently in, e.g. sh and csh. Moreover, the GNU
implementations of  'cp', 'mv', and 'cat' -- each a very important
system command -- have many non-POSIX options (just check out the man
pages).

> Sure, new behaviour has been added, and in the case of lots of the GNU
> stuff, the new behaviour is almost always used, but it has to be
> enabled somehow. The defaults have remained the same! This is
> important! Do you know how many shell scripts the average sysadmin has
> in his toolkit? Scripts that were written years ago, and have been
> honed to a razor-sharp point, scripts that might actually be bug-free?
> Now, what would happen if the *default* behaviour of 'rm' or 'mv'
> changed? Most likely, a catastrophe!
>
> This is why aliases like Red Hat sets up for rm, mv, and cp are a
> terrible idea in my opinion. Creating aliases like 'safe-rm' and so on
> would be much better, because then the conditioning would lead to
> 'bash: safe-rm: command not found', instead of 'rm' "failing" to
> prompt you and thus enabling you to do untold damage to a production
> system.

I do value the opinion of the folks here on -dev: I'd love to hear
feedback on my idea, but I'd rather not rehash old arguments with which
I mostly agree! I'm not advocating any changes to the default behavior
of 'rm'. Indeed, the solution I proposed -- while not perfect -- does
preserve full backward-compatability. Please read it, and let me know
what you think.

>> As for nonstandard options, that's exactly what I propose. Appealing
>> to tradition myself, I should point out that Linux has a rich history
>> of adding nonstandard options to ancient UNIX commands.
>
> I assume that, in this context, by "Linux", you actually mean "GNU",
> right?

I thought the distinction was pretty clear[1]. Let's save the
"GNU/Linux" flame-war for some other time. :)

But my point stands. The GNU project has been adding nonstandard options
to core UNIX commands since its inception. So why not 'rm'?

-Eamon

[1] It would be cool to make file-unlinking "safer" in kernel space, but
I digress.



--
gentoo-dev@g.o mailing list