GNU bug report logs - #42529
configure: error: Your 'rm' program is bad, sorry.

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 42529 in the body.
You can then email your comments to 42529 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: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: bug-automake <at> gnu.org
Subject: configure: error: Your 'rm' program is bad, sorry.
Date: Sat, 25 Jul 2020 09:27:31 -0500 (CDT)

On an OpenIndiana system without the GNU utilities in the executable 
search path, configure of autoconf-2.69b fails spectacularly.  This 
failure was actually not unexpected since it is due to a ksh93 
built-in bug which was never fixed.  The problem does not occur if I 
do this (forcing use of bash, which is in the executable search path):

CONFIG_SHELL=/usr/bin/bash /home/bfriesen/src/gnu/autoconf-2.69b/configure

This is what actually happened:

weerd:~/build/autoconf-2.69b% /home/bfriesen/src/gnu/autoconf-2.69b/configure
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
Usage: rm [-cFdfirRuv] file ...
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.

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.

configure: error: Your 'rm' program is bad, sorry.

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

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

From: Karl Berry <karl <at> freefriends.org>
To: bfriesen <at> simple.dallas.tx.us
Cc: 42529 <at> debbugs.gnu.org
Subject: Re: bug#42529: configure: error: Your 'rm' program is bad, sorry.
Date: Fri, 20 Nov 2020 19:20:01 -0700

Hi Bob - (sorry for the delayed reply)

    On an OpenIndiana system without the GNU utilities 
    ...
    Usage: rm [-cFdfirRuv] file ...]

So, it seems that system's rm does not accept "rm -f" (with no file
operands)? (I don't have access to any such system to check.)  If so, it
seems the error message is correctly reporting the state of things,
including the possible workaround, so I don't see anything to do?
Closing this now. Feel free to reopen (or just reply) if there is
something more automake should be doing. Thanks for the report. -k

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

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Karl Berry <karl <at> freefriends.org>
Cc: 42529 <at> debbugs.gnu.org
Subject: Re: bug#42529: configure: error: Your 'rm' program is bad, sorry.
Date: Sat, 21 Nov 2020 08:44:40 -0600 (CST)

On Fri, 20 Nov 2020, Karl Berry wrote:

> Hi Bob - (sorry for the delayed reply)
>
>    On an OpenIndiana system without the GNU utilities
>    ...
>    Usage: rm [-cFdfirRuv] file ...]
>
> So, it seems that system's rm does not accept "rm -f" (with no file
> operands)? (I don't have access to any such system to check.)  If so, it
> seems the error message is correctly reporting the state of things,
> including the possible workaround, so I don't see anything to do?
> Closing this now. Feel free to reopen (or just reply) if there is
> something more automake should be doing. Thanks for the report. -k

The "system's" rm in this case is ksh93's built-in rm emulation.

As we all know, the shell attempts to expand arguments before passing 
them to a command.

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.

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

Previous Next

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