bug#10828: [RFC] POSIX will say running "rm -f" with no argument is OK
On 11 Dec 2021 23:19, Moritz Klammler wrote: > An alternative trick which I have used in my code and found much less > disturbing is to prepend an arbitrary, hopefully non-existent, file name > so the list of arguments will never be empty even if the variable is. > > rm -f NOTFOUND $(VAR) i think this is an interesting route. we could do: rm -f $(am__rm_f_notfound) ... and am__rm_f_notfound could be set based on the configure test. am__rm_f_notfound = WORKAROUND_RM_F_BUG that way most people won't see any noise. -mike signature.asc Description: PGP signature
bug#10828: rm -f # no more args failure?
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
Re: rm -f # no more args failure?
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
