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

2021-12-14 Thread Bob Friesenhahn 

On Mon, 13 Dec 2021, Karl Berry wrote:


   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?


Yes, that must be the case.  I updated my PATH to avoid the behavior.


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.


It does still exist in many deployed systems which have not yet been 
updated.  In a year or two there will be fewer systems which lack the 
updated ksh93.



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.


The cost is more a matter of lost execution time due to the fork/exec 
than annoying noise.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

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

2021-12-13 Thread 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