Re: loadables/rm not POSIX compliant

[Eli Schwartz]

On 5/28/19 10:38 AM, Chet Ramey wrote:
> On 5/28/19 8:32 AM, Tim Rühsen wrote:
> 
>> configure: error: Your 'rm' program is bad, sorry.
>> #########
>>
>> Is it possible to fix the loadable 'rm' command ?
>> Let me know if you want me to provide a patch.
> 
> Well, it's hard to know exactly what the problem is here, despite the
> volumes of text produced, because the error message doesn't include the
> command it tried.
> 
> I assume we can fix this particular problem by having rm return 0 if there
> aren't any operands and -f was supplied. That fix is attached.
> 
> If it's somthing else, there is code in bash, used by the loadable
> builtins, to return a special status that causes the execution code to fall
> back to the disk version of a command. The `rm' loadable already uses it
> for `-i'. We just need to add it for additional cases.

I've found the following text inside a recently generated configure script:

# POSIX will say in a future version that running "rm -f" with no argument
# is OK; and we want to be able to make that assumption in our Makefile
# recipes.  So use an aggressive probe to check that the usage we want is
# actually supported "in the wild" to an acceptable degree.
# See automake bug#10828.
# To make any issue more visible, cause the running configure to be aborted
# by default if the 'rm' program in use doesn't match our expectations; the
# user can still override this though.
if rm -f && rm -fr && rm -rf; then : OK; else
  cat >&2 <<'END'
Oops!

Your 'rm' program seems unable to run without file operands specified
on the command line, even when the '-f' option is present.  This is contrary
[...]

It seems that it is indeed trying `rm -f` on its own (as well as -rf and
-fr), so I guess that patch should work.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

signature.asc
Description: OpenPGP digital signature