tags 15518 wontfix close 15518 thanks On 09/30/2013 02:49 AM, Tim Rice wrote:> > Reporting as requested. > > checking for a BSD-compatible install... > /opt/src/gnu/m4-1.4.17/build-aux/install-sh -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... > /opt/src/gnu/m4-1.4.17/build-aux/install-sh -c -d > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... no > UX:rm: ERROR: Incorrect usage > UX:rm: TO FIX: Usage: rm [-fiRr] 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 > [snip] > configure: error: Your 'rm' program is bad, sorry. > ^^^ > Bad? I don't think so. Old? Sure. > > PATH=/usr/bin:/opt/bin:/usr/ccs/bin:/usr/ucb:/usr/gnu/bin:/usr/java/bin:/usr/local/bin:/homes/tim/bin/UnixWare > > config.guess says i686-unknown-sysv5UnixWare7.1.4 > > My suggestion: install GNU rm, or adjust your PATH in case you have already another better (errm, younger :-) 'rm' installed . Future versions of automake (ETA still undetermined) will require an 'rm' program that doesn't choke when invoked with the "-f" option and no arguments. Also, the next version of POSIX will mandate such a behaviour.
For more information and background, see: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10828 I'm closing the bug because the plan of requiring argumentless "rm -f" to just work remains in place; the request for a report that is issued by the script (and that prompted you to open this bug report) is more to allow us to have some gauge of how many systems we are going to affect with that change (yours is the first one so far), rather than to decide whether to go along with it. Thanks, Stefano
