bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK

[Moritz Klammler]

Hi folks,

hope you don't mind an outsider (occasional Autotools user) joining the 
discussion with some trivia.

On 12/11/21 22:52, Karl Berry wrote:
> Hi Mike, Peter,
>
>       > or do we document that we expect `rm -f` to work,
>
> I don't see a reason to break working code wrt rm -f merely for cosmetic
> purposes.
>    test -z "$(VAR)" || rm -f $(VAR)
> does not actually seem "awful" to me. And I fail to see any significant
> gain by simplifying it.

I do have to say that I found it visually disturbing and the noise makes 
it harder for me to understand what an Automake recipe does. Especially 
when not looking at the code but the expended commands as printed during 
execution.

> Whatever POSIX says, we can be sure that reality differs.
> Although systems that fail on "rm -f" are few and far between by now,
> they are not nonexistent. So why break them?
>
> My idea is to let the existing code stand (forever).
>
> In the alternative, I agree with Peter that at least providing an
> overridable variable would be desirable. --thanks, karl.

An alternative trick which I have used in my code and found much less 
disturbing is to prepend an arbitrary, hopefully non-existent, file name 
so the list of arguments will never be empty even if the variable is.

rm -f NOTFOUND $(VAR)

Note that the suggested

RM = rm -f
$(RM) $(VAR)

makes it very easy to inject this behavior; just set RM="rm -f NOTFOUND" 
and you're good to go. You don't have to be able to expand the argument 
list twice, which would be less trivial to inject.

I'm not aware of any situation where this trick doesn't work.

OpenPGP_signature
Description: OpenPGP digital signature