GNU bug report logs - #10819
[BUG][RM]

Previous Next

Full log

View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: "10819 <at> debbugs.gnu.org" <10819 <at> debbugs.gnu.org>, Davide Brini <dave_br <at> gmx.com>, "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Subject: bug#10819: [BUG][RM]
Date: Thu, 16 Feb 2012 18:04:23 +0100

Eric Blake wrote:
> On 02/16/2012 03:59 AM, Jim Meyering wrote:
>>> I think Davide's point is not about the # comment ... rm won't see
>>> that on argv anyway. The point is that 'rm -f' does not complain about
>>> missing operands while 'rm' does:
>>>
>>>   $ rm
>>>   rm: missing operand
>>>   Try `rm --help' for more information.
>>>   $ rm -f
>>>   $
>>>
>>> According to the info, '-f' just silences error messages for files
>>> which do not exist (and never to prompt for confirmation), but why
>>> should it also affect the "missing operand" message?
>>
>> Two reasons:
>>
>>  - that's what rm -f has always done
>>  - because that's more useful.  Otherwise, "rm -rf $file_list" would
>>    have to be wrapped in code to handle specially the case in which
>>    $file_list is empty.
>
> You can always use 'rm -rf dummy $file_list' without having to check for

That would have an undesirable side-effect if ./dummy happens to exist.

> whether $file_list is empty, but yes, that is the primary reasoning why
> -f with no options behaves differently than any other case with no options.
>
> FYI: I just opened a POSIX bug report, asking that this usage be

Thanks.  I noticed the lack upon a cursory reading while writing
the reasons above (wanted to add "because POSIX requires it"), but
hadn't made time to go back and confirm.

> codified (since everyone that I tested already does it):
> http://austingroupbugs.net/view.php?id=542

Previous Next

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