bug#10828: rm -f # no more args failure?

[Karl Berry]

    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