GNU bug report logs - #12339
Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

Previous Next

Full log

View this message in rfc822 format

From: Linda Walsh <coreutils <at> tlinx.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: Bob Proulx <bob <at> proulx.com>, 12339 <at> debbugs.gnu.org
Subject: bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is	documented to do so.
Date: Fri, 07 Sep 2012 14:30:50 -0700

Eric Blake wrote:
> 
> You therefore may have a valid point that POSIX standardized something
> that did not match existing practice at the time, and therefore, it
> would be reasonable to propose a POSIX defect that requires early
> failure on "..", but changes the behavior on "." and "/" to only permit,
> but not require, early failure.  However, I just checked, and the
> prohibition for an early exit on "." has been around since at least
> POSIX 2001, so you are now coming into the game at least 11 years late.
----
	Those changes only started hitting the field a few years ago.

	Bash just started working to adopted the 2003 standard with
it's 4.0 version -- before that it was 1999 -- I didn't even know
there was a 2001....

	Except that trying to get them to change things now, I'd encounter
the same arguments I get here -- that users expect to be able have "-f"
not really mean force -- and to report errors on ".".

	Not that I believe that, -- I just think most users aren't
aware or don't care, but that would be the reasoning.   I get it here,
why would I expect someone who's job is to come up with lame rules that
defy standard practice (last I looked they were proposing to ban "space"
(as well as 0x01-0x1f) in file names).   Attempting to deal with people
who want to turn POSIX into a restriction document -- not a standard
reflecting current implementations, is well beyond my social abilities.

	I can't even get engineers -- when faced with clear evidence
of programs that put out inconsistent output to fix them.  They know it's
bad output -- and even warn that they are about to do the wrong thing
in warnings.   Somehow this is considered preferable to doing something
useful.

	So expecting a group that is heavily into bureaucracy to listen to
reason just doesn't seem like a reasonable expectation.

	I did go to their website though and see what they were discussing,
and when I saw that sentiment was going in favor of limiting allowed characters
in filenames, I was to ill to stay.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.