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 #48 received at 21084 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Linda Walsh <coreutils <at> tlinx.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: Sun, 02 Aug 2015 22:23:46 -0700

Linda Walsh wrote:
>
>> time rm -fr .
> 183.23sec 0.69usr 36.25sys (20.16% cpu)
>> time find . ! -name . -prune -exec rm -fr {} +
> 219.58sec 0.87usr 40.81sys (18.98% cpu) -- about 36 seconds (~20%) longer

Benchmarks like this are often suspect since a lot of it depends on factors that 
are hard to reproduce.  That being said, when I tried a similar benchmark on my 
machine, the 'find' solution was over 30% faster.  In any event the minor 
performance improvements we're talking about would not be a compelling argument 
for adding UI complexity to 'rm', even if the 'rm' approach was uniformly faster

> But you also didn't address points (3), (4) or (5)..

They aren't a problem either.  As I mentioned, the "find" approach conforms to 
POSIX and so is quite portable; that covers (3).  If you don't want to cross 
file system boundaries, add the POSIX-required -xdev option to 'find' and the 
GNU extension --one-file-system argument to 'rm'; that covers (4).  And the 
example already uses rm's -f option; that covers (5).

Previous Next

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