GNU bug report logs - #10828
POSIX will say running "rm -f" with no argument is OK

Previous Next

Package: automake;

Reported by: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Date: Thu, 16 Feb 2012 20:44:01 UTC

Severity: wishlist

Done: Mike Frysinger <vapier <at> gentoo.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Thu, 16 Feb 2012 20:44:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefano Lattarini <stefano.lattarini <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-automake <at> gnu.org. (Thu, 16 Feb 2012 20:44:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <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




Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Thu, 03 Jan 2013 19:15:02 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 10828 <at> debbugs.gnu.org
Subject: [RFC] POSIX will say running "rm -f" with no argument is OK
Date: Thu, 03 Jan 2013 20:14:36 +0100
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 ;-)

Regards,
  Stefano




Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Wed, 09 Jan 2013 19:15:01 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake-patches <at> gnu.org
Cc: 10828 <at> debbugs.gnu.org
Subject: [FYI] plans: automake 1.14 is to assume "rm -f" with no args is OK
Date: Wed,  9 Jan 2013 20:14:29 +0100
See automake bug#10828.

* PLANS/rm-f-without-args.txt: New.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 PLANS/rm-f-without-args.txt | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 PLANS/rm-f-without-args.txt

diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt
new file mode 100644
index 0000000..d5f96eb
--- /dev/null
+++ b/PLANS/rm-f-without-args.txt
@@ -0,0 +1,40 @@
+Summary
+-------
+
+POSIX will say in a future version that calling "rm -f" with no argument
+is OK; and this sensible behaviour seem to be already very widespread in
+"the wild" (and possibly lacking only on those systems that are well on
+their way to obsolescence).
+
+Se we'd like to simplify several automake-generated "cleaning" rules
+accordingly, to get rid of the awful idiom:
+
+  test -z "$(VAR)" || rm -f $(VAR)
+
+See automake bug#10828.
+
+For Automake 1.13.2 (or 1.13.3)
+-------------------------------
+
+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; complain loudly (but not with a fatal error) if this is
+not the case, and tell the user to report the situation to us.
+
+For Automake 1.14
+-----------------
+
+Make any failure in the configure-time probe check introduced by the
+previous point fatal; and in case of failure, also suggest to the user
+to install an older version of GNU coreutils to work around the
+limitation of his system (this version should be old enough not to
+be bootstrapped with Automake 1.14, otherwise the user will face a
+bootstrapping catch-9).
+
+In all our recipes, start assuming "rm -f" with no argument is OK;
+simplify and de-uglify the recipes accordingly.
+
+For Automake 1.15
+-----------------
+
+Remove the runtime probe altogether.
-- 
1.8.1.rc3.192.g2d0029e





Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Wed, 16 Jan 2013 12:15:02 GMT) Full text and rfc822 format available.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: automake-patches <at> gnu.org
Cc: 10828 <at> debbugs.gnu.org
Subject: [PATCH] init.m4: add probe to check "rm -f" without args work
Date: Wed, 16 Jan 2013 13:13:18 +0100
On 01/09/2013 08:14 PM, Stefano Lattarini wrote:
> See automake bug#10828.
> 
> * PLANS/rm-f-without-args.txt: New.
> 
> Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
> ---
>  PLANS/rm-f-without-args.txt | 40 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>  create mode 100644 PLANS/rm-f-without-args.txt
> 
> diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt
> new file mode 100644
> index 0000000..d5f96eb
> --- /dev/null
> +++ b/PLANS/rm-f-without-args.txt
> @@ -0,0 +1,40 @@
> +Summary
> +-------
> +
> +POSIX will say in a future version that calling "rm -f" with no argument
> +is OK; and this sensible behaviour seem to be already very widespread in
> +"the wild" (and possibly lacking only on those systems that are well on
> +their way to obsolescence).
> +
> +Se we'd like to simplify several automake-generated "cleaning" rules
> +accordingly, to get rid of the awful idiom:
> +
> +  test -z "$(VAR)" || rm -f $(VAR)
> +
> +See automake bug#10828.
> +
> +For Automake 1.13.2 (or 1.13.3)
> +-------------------------------
> +
> +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; complain loudly (but not with a fatal error) if this is
> +not the case, and tell the user to report the situation to us.
> +
Here is a patch implementing this first part of the plan.  Note that, in
order to improve the visibility of the loud warning, I have made it fatal
by default; the user will still be able to instruct configure to continue
anyway by setting the ACCEPT_INFERIOR_RM_PROGRAM environment variable to
"yes" (that knob is mentioned in the fatal error message).

I will push in a couple of days if there is no objection.

Regards,
  Stefano

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

From f78b0f0b2741fcdd4e21151758a8a75ddaa8aa17 Mon Sep 17 00:00:00 2001
Message-Id: <f78b0f0b2741fcdd4e21151758a8a75ddaa8aa17.1358338329.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Sat, 12 Jan 2013 19:20:54 +0100
Subject: [PATCH] init.m4: add probe to check "rm -f" without args work

See automake bug#10828.

POSIX will say in a future version that running "rm -f" with no argument
is OK: <http://austingroupbugs.net/view.php?id=542>).

We want to be able to make that assumption in our Makefile recipes.
So we introduce an aggressive probe to check that the usage we want is
actually supported "in the wild" to an acceptable degree.

* m4/init.m4 (AM_INIT_AUTOMAKE): Implement the probe.  To make any issue
more visible, cause the running configure to be aborted by default if
the 'rm' program in use doesn't match our expectations; the user can
still override this though, by setting the ACCEPT_INFERIOR_RM_PROGRAM
environment variable to "yes".

* t/spy-rm.tap: Update heading comments.
* t/rm-f-probe.sh: New test.
* t/list-of-tests.mk: Add it.
* PLANS/rm-f-without-args.txt: Adjust.

Signed-off-by: Stefano Lattarini <stefano.lattarini <at> gmail.com>
---
 PLANS/rm-f-without-args.txt |  8 ++---
 m4/init.m4                  | 43 +++++++++++++++++++++++++-
 t/list-of-tests.mk          |  1 +
 t/rm-f-probe.sh             | 74 +++++++++++++++++++++++++++++++++++++++++++++
 t/spy-rm.tap                |  8 ++---
 5 files changed, 125 insertions(+), 9 deletions(-)
 create mode 100755 t/rm-f-probe.sh

diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt
index 5d39e22..5362f98 100644
--- a/PLANS/rm-f-without-args.txt
+++ b/PLANS/rm-f-without-args.txt
@@ -13,13 +13,13 @@ accordingly, to get rid of the awful idiom:

 See automake bug#10828.

-For Automake 1.13.2 (or 1.13.3)
--------------------------------
+For Automake 1.13.2 (DONE)
+--------------------------

 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; complain loudly (but not with a fatal error) if this is
-not the case, and tell the user to report the situation to us.
+being run on; complain loudly if this is not the case, and tell the
+user to report the situation to us.

 For Automake 1.14
 -----------------
diff --git a/m4/init.m4 b/m4/init.m4
index c5af65c..ce64a6c 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -117,7 +117,48 @@ dnl macro is hooked onto _AC_COMPILER_EXEEXT early, see below.
 AC_CONFIG_COMMANDS_PRE(dnl
 [m4_provide_if([_AM_COMPILER_EXEEXT],
   [AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])])dnl
-])
+
+# POSIX will say in a future version that running "rm -f" with no argument
+# is OK; and we want to be able to make that assumption in our Makefile
+# recipes.  So use an aggressive probe to check that the usage we want is
+# actually supported "in the wild" to an acceptable degree.
+# See automake bug#10828.
+# To make any issue more visible, cause the running configure to be aborted
+# by default if the 'rm' program in use doesn't match our expectations; the
+# user can still override this though.
+if rm -f && rm -fr && rm -rf; then : OK; else
+  cat >&2 <<'END'
+Oops!
+
+Your 'rm' program seems unable to run without file operands specified
+on the command line, even when the '-f' option is present.  This is contrary
+to the behaviour of most rm programs out there, and not conforming with
+the upcoming POSIX standard: <http://austingroupbugs.net/view.php?id=542>
+
+Please tell bug-automake <at> gnu.org about your system, including the value
+of your $PATH and any error possibly output before this message.  This
+can help us improve future automake versions.
+
+END
+  if test x"$ACCEPT_INFERIOR_RM_PROGRAM" = x"yes"; then
+    echo 'Configuration will proceed anyway, since you have set the' >&2
+    echo 'ACCEPT_INFERIOR_RM_PROGRAM variable to "yes"' >&2
+    echo >&2
+  else
+    cat >&2 <<'END'
+Aborting the configuration process, to ensure you take notice of the issue.
+
+You can download and install GNU coreutils to get an 'rm' implementation
+that behaves properly: <http://www.gnu.org/software/coreutils/>.
+
+If you want to complete the configuration process using your problematic
+'rm' anyway, export the environment variable ACCEPT_INFERIOR_RM_PROGRAM
+to "yes", and re-run configure.
+
+END
+    AC_MSG_ERROR([Your 'rm' program is bad, sorry.])
+  fi
+fi])

 dnl Hook into '_AC_COMPILER_EXEEXT' early to learn its expansion.  Do not
 dnl add the conditional right here, as _AC_COMPILER_EXEEXT may be further
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 44f598e..0f5dbee 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -953,6 +953,7 @@ t/remake-macrodir.sh \
 t/remake-timing-bug-pr8365.sh \
 t/reqd2.sh \
 t/repeated-options.sh \
+t/rm-f-probe.sh \
 t/rulepat.sh \
 t/self-check-cc-no-c-o.sh \
 t/self-check-configure-help.sh \
diff --git a/t/rm-f-probe.sh b/t/rm-f-probe.sh
new file mode 100755
index 0000000..1cb220a
--- /dev/null
+++ b/t/rm-f-probe.sh
@@ -0,0 +1,74 @@
+#! /bin/sh
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Verify our probe that checks that "rm -f" doesn't complain if called
+# without file operands works as expected.  See automake bug#10828.
+
+. test-init.sh
+
+echo AC_OUTPUT >> configure.ac
+: > Makefile.am
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE
+
+mkdir bin
+cat > bin/rm <<'END'
+#!/bin/sh
+set -e; set -u;
+PATH=$original_PATH; export PATH
+rm_opts=
+while test $# -gt 0; do
+  case $1 in
+    -*) rm_opts="$rm_opts $1";;
+     *) break;;
+  esac
+  shift
+done
+if test $# -eq 0; then
+  echo "Oops, fake rm called without arguments" >&2
+  exit 1
+else
+  exec rm $rm_opts "$@"
+fi
+END
+chmod a+x bin/rm
+
+original_PATH=$PATH
+PATH=$(pwd)/bin$PATH_SEPARATOR$PATH
+export PATH original_PATH
+
+rm -f && exit 99 # Sanity check.
+
+./configure 2>stderr && { cat stderr >&2; exit 1; }
+cat stderr >&2
+
+grep "'rm' program.* unable to run without file operands" stderr
+$FGREP "tell bug-automake <at> gnu.org about your system" stderr
+$FGREP "install GNU coreutils" stderr
+$EGREP "(^| |')ACCEPT_INFERIOR_RM_PROGRAM($| |')" stderr
+
+ACCEPT_INFERIOR_RM_PROGRAM=yes; export ACCEPT_INFERIOR_RM_PROGRAM
+
+./configure
+$MAKE
+$MAKE distcheck
+
+# For the sake of our exit trap.
+PATH=$original_PATH; export PATH
+
+:
diff --git a/t/spy-rm.tap b/t/spy-rm.tap
index 29840ab..3b8dd2d 100755
--- a/t/spy-rm.tap
+++ b/t/spy-rm.tap
@@ -19,10 +19,10 @@
 # to hold on all non-museum systems, and will soon be mandated
 # by POSIX as well) in future version of automake, to simplify
 # automake-provided cleanup rules.
-# References:
-#  <http://lists.gnu.org/archive/html/bug-autoconf/2012-02/msg00002.html>
-#  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10819>
-#  <http://austingroupbugs.net/view.php?id=542>
+# See automake bug#10828.
+# Other references:
+# <http://lists.gnu.org/archive/html/bug-autoconf/2012-02/msg00002.html>
+# <http://austingroupbugs.net/view.php?id=542>

 am_create_testdir=empty
 . test-init.sh
-- 
1.8.1.rc3.192.g2d0029e




Added blocking bug(s) 19692 Request was from Mike Frysinger <vapier <at> gentoo.org> to control <at> debbugs.gnu.org. (Fri, 10 Dec 2021 05:45:02 GMT) Full text and rfc822 format available.

Added blocking bug(s) 22074 Request was from Mike Frysinger <vapier <at> gentoo.org> to control <at> debbugs.gnu.org. (Fri, 10 Dec 2021 05:45:02 GMT) Full text and rfc822 format available.

Added blocking bug(s) 23563 Request was from Mike Frysinger <vapier <at> gentoo.org> to control <at> debbugs.gnu.org. (Fri, 10 Dec 2021 05:45:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Fri, 10 Dec 2021 05:48:02 GMT) Full text and rfc822 format available.

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 10828 <at> debbugs.gnu.org
Subject: Re: [RFC] POSIX will say running "rm -f" with no argument is OK
Date: Fri, 10 Dec 2021 00:47:46 -0500
[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, inline)]

Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Fri, 10 Dec 2021 23:34:01 GMT) Full text and rfc822 format available.

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

From: Peter Johansson <trojkan <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>, 10828 <at> debbugs.gnu.org
Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument
 is OK
Date: Sat, 11 Dec 2021 09:33:40 +1000
Hi Mike,

On 10/12/21 15:47, Mike Frysinger wrote:
> 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 ...

FWIW, automake is not needed to build and install GNU coreutils from a 
released tarball.

Cheers,

Peter






Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Sat, 11 Dec 2021 05:15:02 GMT) Full text and rfc822 format available.

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 10828 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument
 is OK
Date: Sat, 11 Dec 2021 00:14:47 -0500
[Message part 1 (text/plain, inline)]
On 11 Dec 2021 09:33, Peter Johansson wrote:
> On 10/12/21 15:47, Mike Frysinger wrote:
> > 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 ...
> 
> FWIW, automake is not needed to build and install GNU coreutils from a 
> released tarball.

the issue isn't about running `automake`, it's about the generated Makefile
using functionality that requires GNU coreutils.  if an empty `rm -f` was
invoked as part of the coreutils build process, then the user would be a
bit stuck.

admittedly it's a bit unlikely to show up outside of `make clean`, but
coreutils is known to do some "extra" things (optional tools, generation
of man pages, etc...), and i haven't fully looked at every place where
automake will generate a `rm -f` pattern.  do we have to self-regulate
every time we try to use that in case it might break the bootstrap flow
of coreutils ?

i'm not saying we have to support this scenario.  i'm just pointing out
that it's not as cut & dry as we might hope it would be.

it probably comes down to being a bit clearer on what autotools' goals are
and what it considers reasonable prerequisites.  the GNU config project has
undergone a bit of lively debate in the last year about whether it can use
POSIX shell features that have been standardized for over 30 years.  it has
decided that it cannot for some.

automake clearly doesn't require GNU make.  the manual says:
> https://www.gnu.org/software/automake/manual/automake.html#Why-Autotools
> * As we have seen, the GNU Build System has a lot of features ...
> * Implementing these features portably is difficult and exhausting. Think of
> writing portable shell scripts, and portable Makefiles, for systems you may
> not have handy. See Portable Shell Programming in The Autoconf Manual, to
> convince yourself.
> * The GNU Autotools take all this burden off your back and provide:
> * Tools to create a portable, complete, and self-contained GNU Build System,
> from simple instructions. Self-contained meaning the resulting build system
> does not require the GNU Autotools.

so how is "portable" being defined ?  clearly it's not "anything in the latest
POSIX standard is fair game, and anything not supporting the latest POSIX
standard is SOL".  i think users of automake would be surprised by that when
automake has a history of producing Makefile's packages that can be reliably
built on older systems.

if POSIX were a hard requirement, automake wouldn't carry support logic for
Microsoft's lib archiver via `ar-lib`.

so circling back, can we see a way of walking the `rm -f` line without the
maintenance burden being too high ?  e.g. a configure test that checks if
`rm -f` exits non-zero, and some Makefile logic that is able to switch in
the test in/out as needed ?  we could set am__rm_f_suppress to - and just
ignore all failures.  it would allow packages to continue to build (if at
the cost of being extra chatty) for such deficient setups.
am__rm_f_suppress = @am__rm_f_suppress@
am__rm_f = $(am__rm_f_suppress)rm -f

or do we document that we expect `rm -f` to work, and if it doesn't on
your system, then hopefully you won't happen to run into the limitation
when building the project (even if `make clean` might break).  i.e. we
turn the configure-time error into a warning, and then just hope for the
best.  nowhere do we use the `test ... || rm -f ...` pattern.

based on the user reports thus far, i'm OK with the latter.
-mike
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Sat, 11 Dec 2021 09:06:02 GMT) Full text and rfc822 format available.

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

From: Peter Johansson <trojkan <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>, 10828 <at> debbugs.gnu.org
Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument
 is OK
Date: Sat, 11 Dec 2021 19:05:42 +1000
Hi Mike,

On 11/12/21 15:14, Mike Frysinger wrote:
> On 11 Dec 2021 09:33, Peter Johansson wrote:
>> On 10/12/21 15:47, Mike Frysinger wrote:
>>> 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 ...
>> FWIW, automake is not needed to build and install GNU coreutils from a
>> released tarball.
> the issue isn't about running `automake`, it's about the generated Makefile
> using functionality that requires GNU coreutils.

Correct. I was sloppy in my analysis. Apologies for the noise.


>   if an empty `rm -f` was
> invoked as part of the coreutils build process, then the user would be a
> bit stuck.
>
> admittedly it's a bit unlikely to show up outside of `make clean`, but
> coreutils is known to do some "extra" things (optional tools, generation
> of man pages, etc...), and i haven't fully looked at every place where
> automake will generate a `rm -f` pattern.  do we have to self-regulate
> every time we try to use that in case it might break the bootstrap flow
> of coreutils ?
>
> i'm not saying we have to support this scenario.  i'm just pointing out
> that it's not as cut & dry as we might hope it would be.
>
> it probably comes down to being a bit clearer on what autotools' goals are
> and what it considers reasonable prerequisites.  the GNU config project has
> undergone a bit of lively debate in the last year about whether it can use
> POSIX shell features that have been standardized for over 30 years.  it has
> decided that it cannot for some.
>
> automake clearly doesn't require GNU make.  the manual says:
>> https://www.gnu.org/software/automake/manual/automake.html#Why-Autotools
>> * As we have seen, the GNU Build System has a lot of features ...
>> * Implementing these features portably is difficult and exhausting. Think of
>> writing portable shell scripts, and portable Makefiles, for systems you may
>> not have handy. See Portable Shell Programming in The Autoconf Manual, to
>> convince yourself.
>> * The GNU Autotools take all this burden off your back and provide:
>> * Tools to create a portable, complete, and self-contained GNU Build System,
>> from simple instructions. Self-contained meaning the resulting build system
>> does not require the GNU Autotools.
> so how is "portable" being defined ?  clearly it's not "anything in the latest
> POSIX standard is fair game, and anything not supporting the latest POSIX
> standard is SOL".  i think users of automake would be surprised by that when
> automake has a history of producing Makefile's packages that can be reliably
> built on older systems.
>
> if POSIX were a hard requirement, automake wouldn't carry support logic for
> Microsoft's lib archiver via `ar-lib`.
>
> so circling back, can we see a way of walking the `rm -f` line without the
> maintenance burden being too high ?  e.g. a configure test that checks if
> `rm -f` exits non-zero, and some Makefile logic that is able to switch in
> the test in/out as needed ?  we could set am__rm_f_suppress to - and just
> ignore all failures.  it would allow packages to continue to build (if at
> the cost of being extra chatty) for such deficient setups.
> am__rm_f_suppress = @am__rm_f_suppress@
> am__rm_f = $(am__rm_f_suppress)rm -f
>
> or do we document that we expect `rm -f` to work, and if it doesn't on
> your system, then hopefully you won't happen to run into the limitation
> when building the project (even if `make clean` might break).  i.e. we
> turn the configure-time error into a warning, and then just hope for the
> best.  nowhere do we use the `test ... || rm -f ...` pattern.

That seems reasonable. I'd say the minimal change would be to at least 
not call 'rm -f' directly but define a variable

RM = rm -f

so a user has some way around potential problems.

Cheers,

Peter





Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Sat, 11 Dec 2021 21:53:02 GMT) Full text and rfc822 format available.

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

From: Karl Berry <karl <at> freefriends.org>
To: trojkan <at> gmail.com, 10828 <at> debbugs.gnu.org
Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument
 is OK
Date: Sat, 11 Dec 2021 14:52:12 -0700
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.

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.




Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Sat, 11 Dec 2021 22:05:01 GMT) Full text and rfc822 format available.

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

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: 10828 <at> debbugs.gnu.org, trojkan <at> gmail.com, stefano.lattarini <at> gmail.com
Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument
 is OK
Date: Sat, 11 Dec 2021 15:04:22 -0700
    it probably comes down to being a bit clearer on what autotools'
    goals are and what it considers reasonable prerequisites.

I'd find it hard to define precisely. As a general rule, I wouldn't want
to lose support for any system that is working now, until we can be
really sure that it is no longer in use anywhere.

For me, compatibility is the dominant criterion for any change.

I made a foolish mistake recently wrt Python variables (a nice new
feature, but I failed to ensure that existing behavior did not change),
but hopefully it is back to normal in 1.16.5.

    about whether it can use POSIX shell features that have been
    standardized for over 30 years.  it has decided that it cannot for
    some.
    
And thank goodness that misguided $(...) change finally got reverted.

    clearly it's not "anything in the latest POSIX standard is fair
    game, and anything not supporting the latest POSIX standard is SOL".

Clearly, and thank goodness for that too :).

Thanks,
Karl




Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Sat, 11 Dec 2021 22:20:02 GMT) Full text and rfc822 format available.

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

From: Moritz Klammler <moritz <at> klammler.eu>
To: bug-automake <at> gnu.org
Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument
 is OK
Date: Sat, 11 Dec 2021 23:19:08 +0100
[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, attachment)]

Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Mon, 13 Dec 2021 22:46:01 GMT) Full text and rfc822 format available.

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

From: Karl Berry <karl <at> freefriends.org>
To: automake <at> gnu.org, 10828 <at> debbugs.gnu.org
Subject: Re: rm -f # no more args failure?
Date: Mon, 13 Dec 2021 15:45:01 -0700
    bf> I thought that systems deriving from OpenSolaris (e.g. Illumos, 
    ...
    However, testing in an empty directory on a system without the 
    upated ksh93 this looks ok to me:

Bob, what you wrote before (approx. a year ago) is here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42529

Ending with:
  Behavior of ksh93 (which has a bug) appears to depend on the PATH 
  setting so it will behave differently if /usr/xpg4/bin or 
  /usr/xpg6/bin appear in the path.

Maybe that is why you didn't see the behavior just now?

In any case, if a broken "rm -f" still exists in a free system as late
as last year, it seems premature to me to force this change now.

I grant Moritz's point that the ubiquitious "test -z ... || rm ..."
adds noise when trying to understand Automake recipes, but IMHO that is
not enough reason to induce this incompatibility.

    mf> collected here as blockers:
    https://debbugs.gnu.org/10828

Thanks. No one active (i.e., me) was aware this was being done, so I
didn't add Bob's report as a blocker when it came in.

I grepped the bug archive for the error message ("Your.*rm.*program")
and didn't see anything other than Bob's, but that could have missed
some.

    there's only 3 reports filed from the last 10 years.

Which I see are:

May 2016 - MKS Platform component 9.X - bugs.gnu.org/23563
Dec 2015 - Unixware 7.1.4 - bugs.gnu.org/22074
Jan 2015 - Qnx 6.3.2 - bugs.gnu.org/19692

Looks like Unixware 7.1.4 may still be current, but since there are no
later reports, I guess they're not really using Automake, or set the
necessary envvar, or something. --karl




Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Tue, 14 Dec 2021 02:05:02 GMT) Full text and rfc822 format available.

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Moritz Klammler <moritz <at> klammler.eu>
Cc: 10828 <at> debbugs.gnu.org
Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument
 is OK
Date: Mon, 13 Dec 2021 21:04:49 -0500
[Message part 1 (text/plain, inline)]
On 11 Dec 2021 23:19, Moritz Klammler wrote:
> 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)

i think this is an interesting route.  we could do:
	rm -f $(am__rm_f_notfound) ...
and am__rm_f_notfound could be set based on the configure test.
	am__rm_f_notfound = WORKAROUND_RM_F_BUG
that way most people won't see any noise.
-mike
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Tue, 14 Dec 2021 14:14:01 GMT) Full text and rfc822 format available.

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

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Karl Berry <karl <at> freefriends.org>
Cc: 10828 <at> debbugs.gnu.org, automake <at> gnu.org
Subject: Re: rm -f # no more args failure?
Date: Tue, 14 Dec 2021 08:13:29 -0600 (CST)
On Mon, 13 Dec 2021, Karl Berry wrote:

>    bf> I thought that systems deriving from OpenSolaris (e.g. Illumos,
>    ...
>    However, testing in an empty directory on a system without the
>    upated ksh93 this looks ok to me:
>
> Bob, what you wrote before (approx. a year ago) is here:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42529
>
> Ending with:
>  Behavior of ksh93 (which has a bug) appears to depend on the PATH
>  setting so it will behave differently if /usr/xpg4/bin or
>  /usr/xpg6/bin appear in the path.
>
> Maybe that is why you didn't see the behavior just now?

Yes, that must be the case.  I updated my PATH to avoid the behavior.

> In any case, if a broken "rm -f" still exists in a free system as late
> as last year, it seems premature to me to force this change now.

It does still exist in many deployed systems which have not yet been 
updated.  In a year or two there will be fewer systems which lack the 
updated ksh93.

> I grant Moritz's point that the ubiquitious "test -z ... || rm ..."
> adds noise when trying to understand Automake recipes, but IMHO that is
> not enough reason to induce this incompatibility.

The cost is more a matter of lost execution time due to the fork/exec 
than annoying noise.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt




Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Wed, 15 Dec 2021 21:49:01 GMT) Full text and rfc822 format available.

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

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: 10828 <at> debbugs.gnu.org, moritz <at> klammler.eu
Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument
 is OK
Date: Wed, 15 Dec 2021 14:48:55 -0700
    > rm -f NOTFOUND $(VAR)
    i think this is an interesting route.  

I agree.

    we could do:
            rm -f $(am__rm_f_notfound) ...
    and am__rm_f_notfound could be set based on the configure test.

Sounds plausible to me. The "only" problem is that there are dozens or
hundreds of places in the code that do rm -f. They would all have to be
inspected and changed (or not) ... -k




Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Thu, 16 Dec 2021 04:04:02 GMT) Full text and rfc822 format available.

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 10828 <at> debbugs.gnu.org, moritz <at> klammler.eu
Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument
 is OK
Date: Wed, 15 Dec 2021 23:03:06 -0500
[Message part 1 (text/plain, inline)]
On 15 Dec 2021 14:48, Karl Berry wrote:
>     > rm -f NOTFOUND $(VAR)
>     i think this is an interesting route.  
> 
> I agree.
> 
>     we could do:
>             rm -f $(am__rm_f_notfound) ...
>     and am__rm_f_notfound could be set based on the configure test.
> 
> Sounds plausible to me. The "only" problem is that there are dozens or
> hundreds of places in the code that do rm -f. They would all have to be
> inspected and changed (or not) ... -k

the issue isn't `rm -f` exactly, it's `rm -f` with a variable that could be
empty.  so that narrows it down at least by half.

if we focus on ones using the pattern `test -z ... || rm -f ...`, there's
barely a dozen of those.  i'm not sure we need to fully audit the tree and
review every `rm`, just do a best effort and wait for feedback (i.e. bugs).

we could add a helper var to further collapse the boiler plate.
	am__rm_f = rm -f $(am__rm_f_notfound)
then the rule is a bit more palatable:
	$(am__rm_f) ...

or if we want to claim namespace and make it something we want to export
for users of automake akin to AC_PROG_LN_S, we could use RM_F.
-mike
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Fri, 17 Dec 2021 03:23:01 GMT) Full text and rfc822 format available.

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

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org, 10828 <at> debbugs.gnu.org
Subject: Re: bug#10828: [RFC] POSIX will say running "rm -f" with no argument
 is OK
Date: Thu, 16 Dec 2021 20:22:49 -0700
Hi Mike,

    the issue isn't `rm -f` exactly, it's `rm -f` with a variable that
    could be empty.

Sure.

    i'm not sure we need to fully audit the tree 

Seems desirable to make a best effort to look at every viable case.

At any rate, it should be reproducible on OpenSolaris etc., as reported
by Bob F earlier in this report. So I hope Bob could try any proposed
patches and check for missing cases.

    we could add a helper var to further collapse the boiler plate.
            am__rm_f = rm -f $(am__rm_f_notfound)
    then the rule is a bit more palatable:
            $(am__rm_f) ...

Personally I find making "rm -f" into a variable less readable
than the original suggestion of:
        rm -f ... $(am__rm_f_notfound)

The minor tweak that comes to my mind is that maybe the variable name
would be better as $(am__rm_f_notfound_file):
        rm -f ... $(am__rm_f_notfound_file)

    or if we want to claim namespace and make it something we want to export
    for users of automake akin to AC_PROG_LN_S, we could use RM_F.

Our hope/belief is that the proposed change would silently fix the
problem.  In which case I don't see a win to doing something in user
namespace, having to document it, etc.

(Incidentally, I'd never want to define a variable as simple as "RM_F"
at this late date. Too much chance of collision ... AM_RM_F would be ok
if we wanted to go this route, but, as I say, I don't see a reason at
the moment.) --thanks, karl.




Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Thu, 17 Feb 2022 09:07:02 GMT) Full text and rfc822 format available.

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: 10828 <at> debbugs.gnu.org
Subject: [PATCH] rm: handle -f w/no arguments gracefully
Date: Thu, 17 Feb 2022 04:06:10 -0500
Fixes automake bug https://bugs.gnu.org/10828.

Delete the configure check that would abort if `rm -f` does not work,
and delete the plans to make this a hard requirement in the future.

Instead, test to see if `rm -f` fails w/out arguments.  If it does,
define am__rm_f such that it always passes at least the "" argument
when deleting files.  If it doesn't fail, then we can omit the "".

Then go through lib/am/ and update places where we use the pattern
`test -z ... || rm -f ...` and replace with $(am__rm_f).

* NEWS: Mention support for `rm -f` w/out arguments.
* PLANS/rm-f-without-args.txt: Remove.
* lib/am/check.am: Use new $(am__rm_f) helper.
* lib/am/clean.am: Likewise.
* lib/am/header-vars.am: Likewise.
* lib/am/inst-vars.am: Likewise.
* lib/am/libs.am: Likewise.
* lib/am/ltlib.am: Likewise.
* lib/am/progs.am: Likewise.
* lib/am/texinfos.am: Likewise.
* m4/init.m4: Delete `rm -f` checks and call _AM_PROG_RM_F.
* m4/rmf.m4: Define new _AM_PROG_RM_F macro.
* t/rm-f-probe.sh: Update test.
---
 NEWS                        |  4 ++++
 PLANS/rm-f-without-args.txt | 40 ------------------------------------
 lib/am/check.am             |  8 ++++----
 lib/am/clean.am             |  4 ++--
 lib/am/header-vars.am       |  4 ++++
 lib/am/inst-vars.am         |  8 +++-----
 lib/am/libs.am              |  2 +-
 lib/am/ltlib.am             |  8 +++-----
 lib/am/progs.am             |  5 ++---
 lib/am/texinfos.am          |  8 +++-----
 m4/init.m4                  | 41 +------------------------------------
 m4/rmf.m4                   | 16 +++++++++++++++
 t/rm-f-probe.sh             | 26 +++++++++++------------
 13 files changed, 55 insertions(+), 119 deletions(-)
 delete mode 100644 PLANS/rm-f-without-args.txt
 create mode 100644 m4/rmf.m4

diff --git a/NEWS b/NEWS
index 74ad6d612560..fbb3f758ce52 100644
--- a/NEWS
+++ b/NEWS
@@ -22,6 +22,10 @@ New in 1.17:
   - Generated file timestamp checks now handle filesystems with sub-second
     timestamp granularity dynamically.
 
+  - Systems with non-POSIX "rm -f" behavior are now supported, and intent to
+    drop support for them has been reversed.  The ACCEPT_INFERIOR_RM_PROGRAM
+    setting no longer exists.
+
 * Obsolescent features:
 
   - py-compile no longer supports Python 0.x or 1.x versions.  Python 2.0,
diff --git a/PLANS/rm-f-without-args.txt b/PLANS/rm-f-without-args.txt
deleted file mode 100644
index b940fc3e9000..000000000000
--- a/PLANS/rm-f-without-args.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-Summary
--------
-
-POSIX will say in a future version that calling "rm -f" with no argument
-is OK; and this sensible behaviour seem to be already very widespread in
-"the wild" (and possibly lacking only on those systems that are well on
-their way to obsolescence).
-
-Se we'd like to simplify several automake-generated "cleaning" rules
-accordingly, to get rid of the awful idiom:
-
-  test -z "$(VAR)" || rm -f $(VAR)
-
-See automake bug#10828.
-
-For Automake 1.14 (DONE)
-------------------------
-
-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; complain loudly if this is not the case, and tell the
-user to report the situation to us.
-
-For Automake 2.0
-----------------
-
-Make any failure in the configure-time probe check introduced by the
-previous point fatal; and in case of failure, also suggest to the user
-to install an older version of GNU coreutils to work around the
-limitation of his system (this version should be old enough not to
-be bootstrapped with Automake 2.0, otherwise the user will face a
-bootstrapping catch-22).
-
-In all our recipes, start assuming "rm -f" with no argument is OK;
-simplify and de-uglify the recipes accordingly.
-
-For Automake 3.0
-----------------
-
-Remove the runtime probe altogether.
diff --git a/lib/am/check.am b/lib/am/check.am
index a7201af76bc0..6648c011d721 100644
--- a/lib/am/check.am
+++ b/lib/am/check.am
@@ -405,8 +405,8 @@ RECHECK_LOGS = $(TEST_LOGS)
 ## ------------------------------------------ ##
 
 check-TESTS: %CHECK_DEPS%
-	@list='$(RECHECK_LOGS)';           test -z "$$list" || rm -f $$list
-	@list='$(RECHECK_LOGS:.log=.trs)'; test -z "$$list" || rm -f $$list
+	@list='$(RECHECK_LOGS)';           $(am__rm_f) $$list
+	@list='$(RECHECK_LOGS:.log=.trs)'; $(am__rm_f) $$list
 ## We always have to remove $(TEST_SUITE_LOG), to ensure its rule is run
 ## in any case even in lazy mode: otherwise, if no test needs rerunning,
 ## or a prior run plus reruns all happen within the same timestamp (can
@@ -414,7 +414,7 @@ check-TESTS: %CHECK_DEPS%
 ## OTOH, this means that, in the rule for '$(TEST_SUITE_LOG)', we
 ## cannot use '$?' to compute the set of lazily rerun tests, lest
 ## we rely on .PHONY to work portably.
-	@test -z "$(TEST_SUITE_LOG)" || rm -f $(TEST_SUITE_LOG)
+	@$(am__rm_f) $(TEST_SUITE_LOG)
 	@set +e; $(am__set_TESTS_bases); \
 	log_list=`for i in $$bases; do echo $$i.log; done`; \
 	trs_list=`for i in $$bases; do echo $$i.trs; done`; \
@@ -432,7 +432,7 @@ check-TESTS: %CHECK_DEPS%
 recheck: all %CHECK_DEPS%
 ## See comments above in the check-TESTS recipe for why remove
 ## $(TEST_SUITE_LOG) here.
-	@test -z "$(TEST_SUITE_LOG)" || rm -f $(TEST_SUITE_LOG)
+	@$(am__rm_f) $(TEST_SUITE_LOG)
 	@set +e; $(am__set_TESTS_bases); \
 ## We must only consider tests that had an unexpected outcome (FAIL
 ## or XPASS) in the earlier run.
diff --git a/lib/am/clean.am b/lib/am/clean.am
index 987e825ba77f..bf7eb81789fe 100644
--- a/lib/am/clean.am
+++ b/lib/am/clean.am
@@ -27,8 +27,8 @@ clean-generic:
 
 distclean-am: distclean-generic clean-am
 distclean-generic:
-	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
+	-$(am__rm_f) $(CONFIG_CLEAN_FILES)
+	-test . = "$(srcdir)" || $(am__rm_f) $(CONFIG_CLEAN_VPATH_FILES)
 %DISTCLEAN_RMS%
 
 ## Makefiles and their dependencies cannot be cleaned by
diff --git a/lib/am/header-vars.am b/lib/am/header-vars.am
index cfc330e6506b..0256faed6d2b 100644
--- a/lib/am/header-vars.am
+++ b/lib/am/header-vars.am
@@ -140,6 +140,10 @@ am__make_dryrun = (target_option=n; $(am__make_running_with_option))
 ## subdirectories, and decide whether to stop at the first error or not.
 am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
 
+## Helper to handle `rm -f` failing with no arguments.
+am__rm_f = rm -f $(am__rm_f_notfound)
+am__rm_rf = rm -rf $(am__rm_f_notfound)
+
 ## Some derived variables that have been found to be useful.
 pkgdatadir = $(datadir)/@PACKAGE@
 pkgincludedir = $(includedir)/@PACKAGE@
diff --git a/lib/am/inst-vars.am b/lib/am/inst-vars.am
index c17dd625d96f..fd35a7de1a16 100644
--- a/lib/am/inst-vars.am
+++ b/lib/am/inst-vars.am
@@ -59,15 +59,13 @@ am__base_list = \
 ## to the directory where the files to be removed are, and to the list of
 ## such files.
 am__uninstall_files_from_dir = { \
-## Some rm implementations complain if 'rm -f' is used without arguments.
-  test -z "$$files" \
 ## At least Solaris /bin/sh still lacks 'test -e', so we use the multiple
 ## tests below instead.  We expect $dir to be either non-existent or a
 ## directory, so the failure we'll experience if it is a regular file
 ## is indeed desired and welcome (better to fail loudly thasn silently).
-    || { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \
-    || { echo " ( cd '$$dir' && rm -f" $$files ")"; \
-         $(am__cd) "$$dir" && rm -f $$files; }; \
+  { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \
+  || { echo " ( cd '$$dir' && rm -f" $$files ")"; \
+       $(am__cd) "$$dir" && $(am__rm_f) $$files; }; \
   }
 
 endif %?FIRST%
diff --git a/lib/am/libs.am b/lib/am/libs.am
index 52413521a088..a5e175e93160 100644
--- a/lib/am/libs.am
+++ b/lib/am/libs.am
@@ -103,4 +103,4 @@ endif %?INSTALL%
 
 .PHONY clean-am: clean-%DIR%LIBRARIES
 clean-%DIR%LIBRARIES:
-	-test -z "$(%DIR%_LIBRARIES)" || rm -f $(%DIR%_LIBRARIES)
+	-$(am__rm_f) $(%DIR%_LIBRARIES)
diff --git a/lib/am/ltlib.am b/lib/am/ltlib.am
index 6e3c065f4300..032f88169bda 100644
--- a/lib/am/ltlib.am
+++ b/lib/am/ltlib.am
@@ -109,7 +109,7 @@ endif %?INSTALL%
 
 .PHONY clean-am: clean-%DIR%LTLIBRARIES
 clean-%DIR%LTLIBRARIES:
-	-test -z "$(%DIR%_LTLIBRARIES)" || rm -f $(%DIR%_LTLIBRARIES)
+	-$(am__rm_f) $(%DIR%_LTLIBRARIES)
 ## 'so_locations' files are created by some linkers (IRIX, OSF) when
 ## building a shared object.  Libtool places these files in the
 ## directory where the shared object is created.
@@ -117,7 +117,5 @@ clean-%DIR%LTLIBRARIES:
 	locs=`for p in $$list; do echo $$p; done | \
 	      sed 's|^[^/]*$$|.|; s|/[^/]*$$||; s|$$|/so_locations|' | \
 	      sort -u`; \
-	test -z "$$locs" || { \
-	  echo rm -f $${locs}; \
-	  rm -f $${locs}; \
-	}
+	echo rm -f $${locs}; \
+	$(am__rm_f) $${locs}
diff --git a/lib/am/progs.am b/lib/am/progs.am
index 8b99ec5a8c54..db3fd9585761 100644
--- a/lib/am/progs.am
+++ b/lib/am/progs.am
@@ -93,9 +93,8 @@ uninstall-%DIR%PROGRAMS:
 	      -e 's/$$/$(EXEEXT)/' \
 ?!BASE?	      -e 'x;s,[^/]*$$,,;G;s,\n,,' \
 	`; \
-	test -n "$$list" || exit 0; \
 	echo " ( cd '$(DESTDIR)$(%NDIR%dir)' && rm -f" $$files ")"; \
-	cd "$(DESTDIR)$(%NDIR%dir)" && rm -f $$files
+	cd "$(DESTDIR)$(%NDIR%dir)" && $(am__rm_f) $$files
 endif %?INSTALL%
 
 
@@ -105,7 +104,7 @@ endif %?INSTALL%
 
 .PHONY clean-am: clean-%DIR%PROGRAMS
 clean-%DIR%PROGRAMS:
-?!LIBTOOL?	-test -z "$(%DIR%_PROGRAMS)" || rm -f $(%DIR%_PROGRAMS)
+?!LIBTOOL?	-$(am__rm_f) $(%DIR%_PROGRAMS)
 ## Under Cygwin, we build 'program$(EXEEXT)'.  However, if this
 ## program uses a Libtool library, Libtool will move it in
 ## '_libs/program$(EXEEXT)' and create a 'program' wrapper (without
diff --git a/lib/am/texinfos.am b/lib/am/texinfos.am
index 4284b1ea76d5..896a2a007b76 100644
--- a/lib/am/texinfos.am
+++ b/lib/am/texinfos.am
@@ -386,14 +386,13 @@ mostlyclean-aminfo:
 ## Use '-rf', not just '-f', because the %*CLEAN% substitutions can also
 ## contain any directory created by "makeinfo --html", as well as the
 ## '*.t2d' and '*.t2p' directories used by texi2dvi and texi2pdf.
-	-rm -rf %MOSTLYCLEAN%
+	-$(am__rm_rf) %MOSTLYCLEAN%
 
 .PHONY clean-am: clean-aminfo
 clean-aminfo:
 ## Use '-rf', not just '-f'; see comments in 'mostlyclean-aminfo'
 ## above for details.
-?TEXICLEAN?	-test -z "%TEXICLEAN%" \
-?TEXICLEAN?	|| rm -rf %TEXICLEAN%
+?TEXICLEAN?	-$(am__rm_rf) %TEXICLEAN%
 
 .PHONY maintainer-clean-am: maintainer-clean-aminfo
 maintainer-clean-aminfo:
@@ -405,7 +404,6 @@ maintainer-clean-aminfo:
 	done
 ## Use '-rf', not just '-f'; see comments in 'mostlyclean-aminfo'
 ## above for details.
-?MAINTCLEAN?	-test -z "%MAINTCLEAN%" \
-?MAINTCLEAN?	|| rm -rf %MAINTCLEAN%
+?MAINTCLEAN?	-$(am__rm_rf) %MAINTCLEAN%
 
 endif %?LOCAL-TEXIS%
diff --git a/m4/init.m4 b/m4/init.m4
index 6ef46d6692e7..e576b935d2a2 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -142,47 +142,8 @@ AC_CONFIG_COMMANDS_PRE(dnl
 [m4_provide_if([_AM_COMPILER_EXEEXT],
   [AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])])dnl
 
-# POSIX will say in a future version that running "rm -f" with no argument
-# is OK; and we want to be able to make that assumption in our Makefile
-# recipes.  So use an aggressive probe to check that the usage we want is
-# actually supported "in the wild" to an acceptable degree.
-# See automake bug#10828.
-# To make any issue more visible, cause the running configure to be aborted
-# by default if the 'rm' program in use doesn't match our expectations; the
-# user can still override this though.
-if rm -f && rm -fr && rm -rf; then : OK; else
-  cat >&2 <<'END'
-Oops!
+AC_REQUIRE([_AM_PROG_RM_F])
 
-Your 'rm' program seems unable to run without file operands specified
-on the command line, even when the '-f' option is present.  This is contrary
-to the behaviour of most rm programs out there, and not conforming with
-the upcoming POSIX standard: <http://austingroupbugs.net/view.php?id=542>
-
-Please tell bug-automake <at> gnu.org about your system, including the value
-of your $PATH and any error possibly output before this message.  This
-can help us improve future automake versions.
-
-END
-  if test x"$ACCEPT_INFERIOR_RM_PROGRAM" = x"yes"; then
-    echo 'Configuration will proceed anyway, since you have set the' >&2
-    echo 'ACCEPT_INFERIOR_RM_PROGRAM variable to "yes"' >&2
-    echo >&2
-  else
-    cat >&2 <<'END'
-Aborting the configuration process, to ensure you take notice of the issue.
-
-You can download and install GNU coreutils to get an 'rm' implementation
-that behaves properly: <https://www.gnu.org/software/coreutils/>.
-
-If you want to complete the configuration process using your problematic
-'rm' anyway, export the environment variable ACCEPT_INFERIOR_RM_PROGRAM
-to "yes", and re-run configure.
-
-END
-    AC_MSG_ERROR([Your 'rm' program is bad, sorry.])
-  fi
-fi
 dnl The trailing newline in this macro's definition is deliberate, for
 dnl backward compatibility and to allow trailing 'dnl'-style comments
 dnl after the AM_INIT_AUTOMAKE invocation. See automake bug#16841.
diff --git a/m4/rmf.m4 b/m4/rmf.m4
new file mode 100644
index 000000000000..2437a9f76a6d
--- /dev/null
+++ b/m4/rmf.m4
@@ -0,0 +1,16 @@
+##                                                          -*- Autoconf -*-
+# Copyright (C) 2022 Free Software Foundation, Inc.
+#
+# This file is free software; the Free Software Foundation
+# gives unlimited permission to copy and/or distribute it,
+# with or without modifications, as long as this notice is preserved.
+
+# _AM_PROG_RM_F
+# ---------------
+# Check whether 'rm -f' without any arguments works.
+# https://bugs.gnu.org/10828
+AC_DEFUN([_AM_PROG_RM_F],
+[am__rm_f_notfound=
+AS_IF([(rm -f && rm -fr && rm -rf) 2>/dev/null], [], [am__rm_f_notfound='""'])
+AC_SUBST(am__rm_f_notfound)
+])
diff --git a/t/rm-f-probe.sh b/t/rm-f-probe.sh
index 9cd3e8814b7d..8463f4fb63c5 100644
--- a/t/rm-f-probe.sh
+++ b/t/rm-f-probe.sh
@@ -14,8 +14,8 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
-# Verify our probe that checks that "rm -f" doesn't complain if called
-# without file operands works as expected.  See automake bug#10828.
+# Verify our probe that checks that "rm -f" behavior works.
+# https://bugs.gnu.org/10828
 
 . test-init.sh
 
@@ -40,8 +40,8 @@ while test $# -gt 0; do
   shift
 done
 if test $# -eq 0; then
-  echo "Oops, fake rm called without arguments" >&2
-  exit 1
+  echo "Oops, fake rm called without arguments" >&2 #DELETE
+  exit 1 #CHANGE
 else
   exec rm $rm_opts "$@"
 fi
@@ -54,19 +54,17 @@ export PATH original_PATH
 
 rm -f && exit 99 # Sanity check.
 
-./configure 2>stderr && { cat stderr >&2; exit 1; }
-cat stderr >&2
-
-grep "'rm' program.* unable to run without file operands" stderr
-$FGREP "tell bug-automake <at> gnu.org about your system" stderr
-$FGREP "install GNU coreutils" stderr
-$EGREP "(^| |')ACCEPT_INFERIOR_RM_PROGRAM($| |')" stderr
+# Check that `rm -f` is detected as broken.
+./configure
+grep '^am__rm_f_notfound = ""$' Makefile
 
-ACCEPT_INFERIOR_RM_PROGRAM=yes; export ACCEPT_INFERIOR_RM_PROGRAM
+# Chagne the `rm -f` behavior to work.
+sed -e '/#DELETE/d' -e '/#CHANGE/s:1:0:' bin/rm > bin/rm.tmp
+cat bin/rm.tmp > bin/rm
 
+# Check that `rm -f` is detected as working.
 ./configure
-$MAKE
-$MAKE distcheck
+grep '^am__rm_f_notfound = *$' Makefile
 
 # For the sake of our exit trap.
 PATH=$original_PATH; export PATH
-- 
2.34.1





Information forwarded to bug-automake <at> gnu.org:
bug#10828; Package automake. (Wed, 23 Feb 2022 21:49:01 GMT) Full text and rfc822 format available.

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

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: 10828 <at> debbugs.gnu.org
Subject: Re: bug#10828: [PATCH] rm: handle -f w/no arguments gracefully
Date: Wed, 23 Feb 2022 14:48:00 -0700
    Subject: bug#10828: [PATCH] rm: handle -f w/no arguments gracefully

Patch looks good to me (just reading through it).
Thanks for doing all that work. -k




bug closed, send any further explanations to 10828 <at> debbugs.gnu.org and Stefano Lattarini <stefano.lattarini <at> gmail.com> Request was from Mike Frysinger <vapier <at> gentoo.org> to control <at> debbugs.gnu.org. (Thu, 24 Feb 2022 03:10:03 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 24 Mar 2022 11:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 5 days ago.

Previous Next


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