configure fails when PATH=/usr/xpg4/bin:/usr/bin on Solaris 11

[Dimitrios Apostolou]

Hello again,

here is the failing log of "configure" (as generated by GNU Autoconf 2.69) 
when executed with altered path on Solaris 11:

$ PATH=/usr/xpg4/bin:/usr/bin  /bin/sh ./configure

checking for a BSD-compatible install... config/install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... config/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... no
checking whether make supports nested variables... no

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 address@hidden 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.
[...]


I'm not sure if this bug belongs to automake or autoconf, but I'm 
reporting this here since it seems relevant to the recent discussion. 
Tracing the shell shows that "rm -f" command fails miserably under /bin/sh 
when executed with an altered path, because it is a shell *built-in* 
command!

Here are some manual executions that showcase this behaviour:

$ PATH=/usr/xpg4/bin:/usr/bin  /bin/sh
$ type rm
rm is a shell builtin version of /usr/xpg4/bin/rm
$ rm -f
Usage: rm [-cFdfirRuv] file ...


NOTE: the message about "/usr/xpg4/bin/rm" is completely bogus as there is 
no such command! Basically what it means is that it is a built-in command, 
presumably of /bin/sh (the current shell).

BUT if I execute /bin/sh with the usual PATH, rm is *not a built-in* and 
configure works fine!

$ PATH=/usr/bin:/usr/xpg4/bin  /bin/sh
$ type rm
rm is a tracked alias for /usr/bin/rm
$ rm -f
$ echo $?
0


NOTE: this happens only on Solaris 11; on Solaris 10 /bin/sh never treats 
"rm" as a built-in.

So is this something to report to automake, as a "broken rm" case? Or is 
it an autoconf because the script fails to re-exec under a sane shell?

Thanks in advance,
Dimitris


P.S. Apparently playing with the PATH was not such a good idea so I'm 
probably undoing this change in my build-environment. It would be nice to 
resolve these issues anyhow!