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? Why does /bin/rm matter in the first place? Thanks for your quick feedback, Ludo’.