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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10819 in the body.
You can then email your comments to 10819 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "jeremy.magrin <at> epitech.eu" <jeremy.magrin <at> epitech.eu>
To: <bug-coreutils <at> gnu.org>
Subject: [BUG][RM]
Date: Wed, 15 Feb 2012 16:05:43 +0100

Hello,

I'm writing to you to inform you of a possible bug in the linux "rm" command.
I've experienced that when using by error the said command as following :
"rm - rf#*"
if there is no file named #*# (* being the same as in the console, anything) in the current directory, rm quits as expected because of the incorrect syntax.
But if there is a file named #*#, rm deletes all the current file's content except the said file.

Regards,

-- 
----------------------
MAGRIN Jérémy
{Epitech.} - Bordeaux
Promo : 2016
mail : jeremy.magrin <at> epitech.eu

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

From: Eric Blake <eblake <at> redhat.com>
To: "jeremy.magrin <at> epitech.eu" <jeremy.magrin <at> epitech.eu>
Cc: 10819 <at> debbugs.gnu.org, control <at> debbugs.gnu.org
Subject: Re: bug#10819: [BUG][RM]
Date: Wed, 15 Feb 2012 15:06:05 -0700

[Message part 1 (text/plain, inline)]

tag 10819 needinfo
thanks

On 02/15/2012 08:05 AM, jeremy.magrin <at> epitech.eu wrote:
> Hello,
> 
> I'm writing to you to inform you of a possible bug in the linux "rm"
> command.
> I've experienced that when using by error the said command as following :
> "rm - rf#*"

That's (probably) not a valid command.  By putting a space between - and
r, you are asking rm to remove the literal files named "-" and any files
that match the glob "rf#*".  Did you mean to type "rm -rf #*" instead,
which says to recursively and without warning remove any files that
match the glob "#*"?

It would help us if your report was actual copy-and-paste contents of
what you really did: ls to list directory contents beforehand, then the
rm call you used, then ls afterwards to show what remains, as well as
how that differs from your expectations.

> if there is no file named #*# (* being the same as in the console,
> anything) in the current directory, rm quits as expected because of the
> incorrect syntax.
> But if there is a file named #*#, rm deletes all the current file's
> content except the said file.

Meanwhile, I'm going to guess that you may be hitting one of our FAQ on
how globbing works, and how to make rm remove what you want it to remove:
https://www.gnu.org/software/coreutils/faq/#Why-doesn_0027t-rm-_002dr-_002a_002epattern-recurse-like-it-should_003f

Look at other FAQ in the vicinity.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: Davide Brini <dave_br <at> gmx.com>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#10819: [BUG][RM]
Date: Thu, 16 Feb 2012 09:30:20 +0100

On Wed, 15 Feb 2012 15:06:05 -0700, Eric Blake <eblake <at> redhat.com> wrote:

> tag 10819 needinfo
> thanks
> 
> On 02/15/2012 08:05 AM, jeremy.magrin <at> epitech.eu wrote:
> > Hello,
> > 
> > I'm writing to you to inform you of a possible bug in the linux "rm"
> > command.
> > I've experienced that when using by error the said command as
> > following : "rm - rf#*"
> 
> That's (probably) not a valid command.  By putting a space between - and
> r, you are asking rm to remove the literal files named "-" and any files
> that match the glob "rf#*".  Did you mean to type "rm -rf #*" instead,
> which says to recursively and without warning remove any files that
> match the glob "#*"?

At least in bash, but I suppose in other shells too,

rm -rf #*

treats the "#*" part as a comment, and (if you remove the "-f") complains
about missing operand to rm.

-- 
D.

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

From: Jim Meyering <jim <at> meyering.net>
To: Davide Brini <dave_br <at> gmx.com>
Cc: 10819 <at> debbugs.gnu.org
Subject: Re: bug#10819: [BUG][RM]
Date: Thu, 16 Feb 2012 09:38:24 +0100

Davide Brini wrote:
...
> At least in bash, but I suppose in other shells too,
>
> rm -rf #*
>
> treats the "#*" part as a comment, and (if you remove the "-f") complains
> about missing operand to rm.

That is the default, but for an interactive shell,
that behavior can be changed:

    $ echo a b # c
    a b
    $ shopt -u interactive_comments
    $ echo a b # c
    a b # c

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

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

Jim Meyering wrote:
> Davide Brini wrote:
> ...
> > At least in bash, but I suppose in other shells too,
> >
> > rm -rf #*
> >
> > treats the "#*" part as a comment, and (if you remove the "-f") complains
> > about missing operand to rm.
> 
> That is the default, but for an interactive shell,
> that behavior can be changed:
> 
>     $ echo a b # c
>     a b
>     $ shopt -u interactive_comments
>     $ echo a b # c
>     a b # c

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?

Have a nice day,
Berny

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

From: Jim Meyering <jim <at> meyering.net>
To: "Voelker\, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Cc: "10819 <at> debbugs.gnu.org" <10819 <at> debbugs.gnu.org>,
	Davide Brini <dave_br <at> gmx.com>
Subject: Re: bug#10819: [BUG][RM]
Date: Thu, 16 Feb 2012 11:59:05 +0100

Voelker, Bernhard wrote:

> Jim Meyering wrote:
>> Davide Brini wrote:
>> ...
>> > At least in bash, but I suppose in other shells too,
>> >
>> > rm -rf #*
>> >
>> > treats the "#*" part as a comment, and (if you remove the "-f") complains
>> > about missing operand to rm.
>>
>> That is the default, but for an interactive shell,
>> that behavior can be changed:
>>
>>     $ echo a b # c
>>     a b
>>     $ shopt -u interactive_comments
>>     $ echo a b # c
>>     a b # c
>
> 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.

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

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

Jim Meyering wrote:

> Voelker, Bernhard 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.

Good point.
That means, the info page could be enhanced to mention that
special case (see below).

Have a nice day,
Berny


From 55d64bcdfdba4726c6e2668066bb25f4bfa6c0b6 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker <mail <at> bernhard-voelker.de>
Date: Thu, 16 Feb 2012 13:29:44 +0100
Subject: [PATCH] doc: document 'rm -f' better
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* doc/coreutils.texi (rm invocation): Mention that the option '-f' also
silences the message for missing operands which is useful in scripts
e.g. for "rm -f $file_list" when $file_list is empty.
* src/rm.c (usage):  Likewise.
Reported by Jérémy Magrin in http://bugs.gnu.org/10819
---
 doc/coreutils.texi |    2 +-
 src/rm.c           |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 02c3a2a..87624c2 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8769,7 +8769,7 @@ The program accepts the following options.  Also see @ref{Common options}.
 @itemx --force
 @opindex -f
 @opindex --force
-Ignore nonexistent files and never prompt the user.
+Ignore nonexistent files, missing operands and never prompt the user.
 Ignore any previous @option{--interactive} (@option{-i}) option.
 
 @item -i
diff --git a/src/rm.c b/src/rm.c
index db525d0..02809f2 100644
--- a/src/rm.c
+++ b/src/rm.c
@@ -135,7 +135,7 @@ usage (int status)
       fputs (_("\
 Remove (unlink) the FILE(s).\n\
 \n\
-  -f, --force           ignore nonexistent files, never prompt\n\
+  -f, --force           ignore nonexistent files and arguments, never prompt\n\
   -i                    prompt before every removal\n\
 "), stdout);
       fputs (_("\
-- 
1.7.7

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

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

Voelker, Bernhard wrote:
> Good point.
> That means, the info page could be enhanced to mention that
> special case (see below).
...
> Subject: [PATCH] doc: document 'rm -f' better
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> * doc/coreutils.texi (rm invocation): Mention that the option '-f' also
> silences the message for missing operands which is useful in scripts
> e.g. for "rm -f $file_list" when $file_list is empty.
> * src/rm.c (usage):  Likewise.
> Reported by Jérémy Magrin in http://bugs.gnu.org/10819
...

Thanks.  I've applied that with these tweaks:

doc: improve 'rm -f' description

diff --git a/THANKS.in b/THANKS.in
index 904bb3e..c8dd75f 100644
--- a/THANKS.in
+++ b/THANKS.in
@@ -276,6 +276,7 @@ Jens Elkner                         elkner <at> imsgroup.de
 Jens Schmidt                        jms <at> jsds.hamburg.com
 Jeph Cowan                          jeph <at> ucar.edu
 Jeremy Maitin-Shepard               jbms <at> cmu.edu
+Jérémy Magrin                       jeremy.magrin <at> epitech.eu
 Jerome Abela                        abela <at> hsc.fr
 Jérôme Zago                         bug-coreutils-ml <at> agt-the-walker.net
 Jesse Kornblum                      kornblum <at> usna.edu
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 87624c2..8c6a287 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8769,7 +8769,7 @@ rm invocation
 @itemx --force
 @opindex -f
 @opindex --force
-Ignore nonexistent files, missing operands and never prompt the user.
+Ignore nonexistent files and missing operands, and never prompt the user.
 Ignore any previous @option{--interactive} (@option{-i}) option.

 @item -i

Message #33 received at 10819-done <at> debbugs.gnu.org (full text, mbox):

From: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: "10819-done <at> debbugs.gnu.org" <10819-done <at> debbugs.gnu.org>,
	Davide Brini <dave_br <at> gmx.com>
Subject: RE: bug#10819: [BUG][RM]
Date: Thu, 16 Feb 2012 15:52:57 +0100

tags 10819 fixed
thanks

Jim Meyering wrote:
> Voelker, Bernhard wrote:
> > Good point.
> > That means, the info page could be enhanced to mention that
> > special case (see below).
> ...
> > Subject: [PATCH] doc: document 'rm -f' better

> Thanks.  I've applied that with these tweaks:

Even better, thank you.

Marking it as done.

Have a nice day,
Berny

Message #34 received at 10819-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: "Voelker\, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Cc: "10819-done <at> debbugs.gnu.org" <10819-done <at> debbugs.gnu.org>,
	Davide Brini <dave_br <at> gmx.com>
Subject: Re: bug#10819: [BUG][RM]
Date: Thu, 16 Feb 2012 15:57:46 +0100

Voelker, Bernhard wrote:
...
> tags 10819 fixed
> thanks
...
> Marking it as done.

Thank you.

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

From: Eric Blake <eblake <at> redhat.com>
To: Jim Meyering <jim <at> meyering.net>
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: Re: bug#10819: [BUG][RM]
Date: Thu, 16 Feb 2012 08:28:21 -0700

[Message part 1 (text/plain, inline)]

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
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
codified (since everyone that I tested already does it):
http://austingroupbugs.net/view.php?id=542

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

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: Re: 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

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
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>, Jim Meyering <jim <at> meyering.net>,
	"Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Subject: Re: bug#10819: [BUG][RM]
Date: Thu, 16 Feb 2012 19:38:57 +0100

Hi Eric.

On 02/16/2012 04:28 PM, Eric Blake wrote:
>
> You can always use 'rm -rf dummy $file_list' without having to check for
> 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
> codified (since everyone that I tested already does it):
> http://austingroupbugs.net/view.php?id=542
> 
Still, I vaguely recall that there are some 'rm' implementations out there
which fails upon "rm -f" (with no arguments); and that's why automake uses
the ugly idiom:

  test -z "$(VAR)" || rm -f $(VAR)

in a lot of recipes.  Now, I can't tell off-hand which systems those were,
nor if they actually exist (and in fact I'd *love* to be proven wrong here,
so that we could simplify a bunch of automake recipes); but a more extensive
probing is needed in this matter I guess.  And if you are right (as I hope),
then this 'rm' feature could be documented in the Autoconf manual.

Regards,
  Stefano

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

From: Eric Blake <eblake <at> redhat.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: "10819 <at> debbugs.gnu.org" <10819 <at> debbugs.gnu.org>,
	Davide Brini <dave_br <at> gmx.com>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	Jim Meyering <jim <at> meyering.net>, "Voelker,
	Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Subject: Re: bug#10819: [BUG][RM]
Date: Thu, 16 Feb 2012 11:58:29 -0700

[Message part 1 (text/plain, inline)]

On 02/16/2012 11:38 AM, Stefano Lattarini wrote:
>> FYI: I just opened a POSIX bug report, asking that this usage be
>> codified (since everyone that I tested already does it):
>> http://austingroupbugs.net/view.php?id=542

By the way, that bug report was accepted in today's Austin Group
meeting, so it will be a POSIX requirement whenever Technical
Corrigendum 2 is released :)

>>
> Still, I vaguely recall that there are some 'rm' implementations out there
> which fails upon "rm -f" (with no arguments); and that's why automake uses
> the ugly idiom:
> 
>   test -z "$(VAR)" || rm -f $(VAR)
> 
> in a lot of recipes.  Now, I can't tell off-hand which systems those were,
> nor if they actually exist (and in fact I'd *love* to be proven wrong here,

As would I.  My tests were pretty extensive, hitting some rather old
machines:

FreeBSD 6.4
AIX 5.1
HP-UX 10.20
IRIX 6.5
Solaris 2.6 (both /bin/rm and /usr/xpg4/bin/rm)
Tru64 UNIX 5.1

In all cases, 'rm' gave a usage message and non-zero status, 'rm -f' was
silent with status 0.

GNU coreutils made the swap back in 1993-03-28 (commit 7735ccac,
fileutils 3.8.3b), and if coreutils was the only holdout that caused us
to implement that automake verbosity, we can safely say that 19 years is
long enough to consider the problem long dead.

> so that we could simplify a bunch of automake recipes); but a more extensive
> probing is needed in this matter I guess.  And if you are right (as I hope),
> then this 'rm' feature could be documented in the Autoconf manual.

Yep, I think that's appropriate, as it is unlikely that we will come up
with any counterexamples any time soon.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: Philip Rowlands <phr+coreutils <at> dimebar.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: "10819 <at> debbugs.gnu.org" <10819 <at> debbugs.gnu.org>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	Jim Meyering <jim <at> meyering.net>, Davide Brini <dave_br <at> gmx.com>,
	Stefano Lattarini <stefano.lattarini <at> gmail.com>, "Voelker,
	Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Subject: Re: bug#10819: [BUG][RM]
Date: Thu, 16 Feb 2012 19:15:14 +0000

On 16/02/2012 18:58, Eric Blake wrote:

>> so that we could simplify a bunch of automake recipes); but a more extensive
>> probing is needed in this matter I guess.  And if you are right (as I hope),
>> then this 'rm' feature could be documented in the Autoconf manual.
>
> Yep, I think that's appropriate, as it is unlikely that we will come up
> with any counterexamples any time soon.

As the now-POSIX-infringing behaviour is simple to detect, couldn't 
automake detect it early and die with a helpful message, or is that 
contrary to its philosophy?

Cheers,
Phil

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Philip Rowlands <phr+coreutils <at> dimebar.com>
Cc: "10819 <at> debbugs.gnu.org" <10819 <at> debbugs.gnu.org>,
	"bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	Jim Meyering <jim <at> meyering.net>, Davide Brini <dave_br <at> gmx.com>,
	bug-automake <at> gnu.org, Eric Blake <eblake <at> redhat.com>, "Voelker,
	Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Subject: POSIX will say running "rm -f" with no argument is OK
Date: Thu, 16 Feb 2012 21:41:03 +0100

Severity: wishlist

[CC:ing bug-automake, so that we won't forget about this issue]

Reference:
  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10819#40>

POSIX will say in a future version that running "rm -f" with no argument is OK;
we might simplify several automake-generated "cleaning" rules accordingly, to
get rid of the awful idiom:

  test -z "$(VAR)" || rm -f $(VAR)

On 02/16/2012 08:15 PM, Philip Rowlands wrote:
> On 16/02/2012 18:58, Eric Blake wrote:
> 
>>> so that we could simplify a bunch of automake recipes); but a more extensive
>>> probing is needed in this matter I guess.  And if you are right (as I hope),
>>> then this 'rm' feature could be documented in the Autoconf manual.
>>
>> Yep, I think that's appropriate, as it is unlikely that we will come up
>> with any counterexamples any time soon.
> 
> As the now-POSIX-infringing behaviour is simple to detect, couldn't automake detect
> it early and die with a helpful message, or is that contrary to its philosophy?
>
Well, that might be an overkill, since it appears that all the non-museum
implementations of 'rm' have the behaviour we want.  But I agree that, in case
we ever stumble upon a system violating this new expectation, adding proper
configure-time probing and warning might be helpful (and might convince the
users of such an inferior system to start using GNU coreutils).

Regards,
  Stefano

Previous Next

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