[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rm -f # no more args failure?
From: |
Karl Berry |
Subject: |
Re: rm -f # no more args failure? |
Date: |
Mon, 13 Dec 2021 15:45:01 -0700 |
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