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
