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