Stefano Lattarini <stefano.lattar...@gmail.com> skribis: > On 12/30/2013 04:44 PM, Ludovic Courtès wrote: >> Stefano Lattarini <stefano.lattar...@gmail.com> skribis: >> >>> On 12/29/2013 10:49 PM, Ludovic Courtès wrote: >> >> [...] >> >>>> However, in general, I think packages should not rely on hardcoded file >>>> names, and instead use AC_PATH_PROG or similar mechanisms to get the >>>> right file name. >>>> >>> Not in this case. The test is a "spy" check that tries to determine >>> whether either >>> (1) the first 'rm' in PATH or >>> (2) '/bin/rm' *if present* >>> is deficient, in that it errors out when the -f option is specified and >>> no non-option argument is passed. If /bin/rm does not exist, it can't >>> be deficient, so the test correctly passes (I assume that happened in >>> your setup, right? >> >> Yes. >> >>>> Would it be possible to change these tests to use ‘rm’ instead of /bin/rm? >>>> What do you think? >>>> >>> That would be a bad idea, because we would miss warning from systems >>> where /bin/rm is deficient but the user has installed a better rm >>> (maybe from GNU coreutils) earlier in PATH. >>> >>> If all you are seeing are few SKIP messages and no failure, I don't >>> think there is any problem to fix; everything is working as intended. >> >> Yes, of course. >> >> However, I’m still wondering: do Automake-generated makefiles and >> Autoconf macros explicitly attempt to use /bin/rm in normal use? >> > Re Automake: not that I'm aware of. Have you any proof this is > not the case?
No; I’m asking because the tests specifically refer to /bin/rm. What’s the reason? Ludo’.
