bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is docu


From: Linda Walsh
Subject: bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.
Date: Thu, 06 Sep 2012 10:40:38 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666



Bernhard Voelker wrote:


On September 6, 2012 at 12:56 PM Linda Walsh <address@hidden> wrote:

Jim Meyering wrote:
Thanks for the patch, but it would be pretty rotten for GNU rm to make
it so "rm -rf ." deletes everything under ".", while all other vendor
rm programs diagnose the POSIX-mandated error.  People would curse us
for making GNU rm remove their precious files when they accidentally ran
that command.
---

Just like people who ran "rm -fr * in /" and didn't get their POSIX
mandated behavior, would curse you?

You are playing Mommy, to people and not allowing them to do what
they are asking the computer to do.

[... and ~40 lines re. Jim, GNU, POSIX, the universe ...]

Dear Linda,

why don't you stick to the point?
----
        I wasn't the one who raised the point of people
cursing Gnu for removing their precious when they accidently or deliberately
tried to invoked rm in a way to generate a non-functional behavior.

        If we were going to talk about them cursing gnu, I thought
I would fully put it in perspective.

        That's what that exposé was about.

        Note -- that it wasn't personally directly, and included listed
facts for a stronger counterpoint to what, admittedly, was likely a lightly
given reason for not changing a default behavior.  It was addressing
that comment, alone.

        You want an on-point counter proposal:

        Might I suggest this as a rational counter proposal.


        If the user issues rm -r ., it issues a warning:

"Do you really wish to remove all files under '.'"?

        That won't break compatible behavior.  Only if the user chooses
the non-default 'force' option "do what I say and shut up", which is not
a default option", would it do the action I suggest.

        In any case, if POSIX_CORRECTLY is set, it will act as per POSIX 
requirements.

        It is TELLING, and important to understand Jim's statement
" Very few people ever set that envvar."  Most people don't want strict POSIX
compatbility -- for reasons exactly like this -- the POSIX isn't about usability, it's
about program portability.  So for interactive use, it wouldn't be something 
most
people would want to use.









reply via email to

[Prev in Thread] Current Thread [Next in Thread]