GNU bug report logs - #16291
Use of /bin/rm

Previous Next

Full log

Message #18 received at 16291 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 16291 <at> debbugs.gnu.org
Subject: Re: bug#16291: Use of /bin/rm
Date: Mon, 30 Dec 2013 17:40:49 +0100

On 12/30/2013 04:44 PM, Ludovic Courtès wrote:
> Stefano Lattarini <stefano.lattarini <at> 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?

Re Autoconf: that should be asked on the autoconf list.

> Why does /bin/rm matter in the first place?
>
> Thanks for your quick feedback,
> Ludo’.
> 

Regards,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.