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

[Mike Frysinger]

On 03 Jan 2013 20:14, Stefano Lattarini wrote:
> Reference:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10828>
> 
> [This is posted also to the automake list to ensure a wider audience.
>  Discussion should continue exclusively on the bug-automake list]
> 
> OK, time to resurrect this thread.
> 
> To summarize, POSIX will say in a future version that running "rm -f"
> with no argument is OK; and that usage seems today portable to all
> systems that are well on their way to obsolescence.
> 
> So, in Automake 1.14, we might start to simplify several automake
> generated "cleaning" rules accordingly, to get rid of the awful
> idiom:
> 
>   test -z "$(VAR)" || rm -f $(VAR)
> 
> In your opinion, can this be done without further fuss, or should we
> add a temporary "probe check" in AM_INIT_AUTOMAKE that verifies that
> the no-args "rm -f" usage is supported on the system configure is
> being run on?  (As for a testsuite probe, that is already present;
> see tests 't/spy-rm.tap', already present in Automake 1.13).
> 
> Comments welcome (and if your answer is "we should add a probe
> check", patches are even more welcome ;-)

what is the game plan here ?  are we intending to keep the backwards
compatible behavior ?  or drop it entirely ?  it seems like if we're
going to go through the effort of adding a configure test to see if
the `rm -f` behavior predates POSIX-2013, then doing an AC_SUBST to
get the backwards compat behavior isn't that much overhead ?

if it's dropped, i'm not sure how users are supposed to fix things.
the error message says to install GNU coreutils, but if GNU coreutils
uses automake and presents the same error ...

in the years since this merged, we've gotten three reports:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19692
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22074
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23563
-mike

signature.asc
Description: PGP signature