GNU bug report logs - #21084
rm appears to no longer be POSIX compliant (as of 2013 edition) re: deleting empty dirs and files under <path>/.

Previous Next

Full log

Message #21 received at 21084 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 21084 <at> debbugs.gnu.org
Subject: Re: bug#21084: rm appears to no longer be POSIX compliant (as of
 2013	edition) re: deleting empty dirs and files under <path>/.
Date: Fri, 31 Jul 2015 16:56:54 -0700

Linda Walsh wrote:
> Andreas Schwab wrote:
>> "If either of the files dot or dot-dot are specified as the basename
>> portion of an operand (that is, the final pathname component) or if an
>> operand resolves to the root directory, rm shall write a diagnostic
>> message to standard error and do nothing more with such operands."
> ----
>     I'll grant it also says you can't remove "/",
>
>     So a special flag "--use_depth_first_inspection" that says not to 
> look at
> a "basename" until it's children have been processed wouldn't be any 
> more out of place than special flags to handle "/" processing, right?
>
>     The fact that they put the ".", ".." and "/" together, outside of
> the 1-4 processing leads one to the idea that they should be treated 
> similarly,
> no?
---
   Since there is no opposition to this, I presume, all you need now
is a patch?

I.e. - POSIX now demands that "/", "." and ".." all be ignored in a 
basename,
yet the some smart gnu folks decided that leaving in a non-default optional
behavior to override the new dumb-down restrictions would best serve the
community.

So I might reason that they would be equally smart and/or use similar logic
to allow a non-default option to remove the dumb-down on the "." path.

NOTE: I have no issue with NOT _attempting_ a delete on "." after doing
the designed depth-first traversal.  Applying the POSIX restriction
on not attempting to delete "." makes perfect sense to me, since
I know that doing so can give inconsistent and "undefined" behavior
depending on the OS, but using "." as a semantic place holder to allow
one to reference a starting point for some action (imagine
using 'find' if '.' was banned as starting point:

 > find '' -type f
 find: ‘’: No such file or directory

*cheers*

Previous Next

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