bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#10819: [BUG][RM]


From: Eric Blake
Subject: Re: bug#10819: [BUG][RM]
Date: Thu, 16 Feb 2012 11:58:29 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0

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   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]