bug#16291: Use of /bin/rm

[Ludovic Courtès]

Stefano Lattarini <address@hidden> skribis:

> On 12/30/2013 04:44 PM, Ludovic Courtès wrote:
>> Stefano Lattarini <address@hidden> 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’.