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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16291 in the body.
You can then email your comments to 16291 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: bug-automake <at> gnu.org
Subject: Use of /bin/rm
Date: Sun, 29 Dec 2013 22:49:53 +0100

Hello!

While upgrading the GNU system to Automake 1.14.1, I noticed that a few
tests emit warnings like this:

--8<---------------cut here---------------start------------->8---
SKIP: t/spy-rm.tap 1 # SKIP /bin/rm not found
PASS: t/spy-rm.tap 2 - rm -f
SKIP: t/spy-rm.tap 3 # SKIP /bin/rm not found
PASS: t/spy-rm.tap 4 - rm -rf
SKIP: t/spy-rm.tap 5 # SKIP /bin/rm not found
PASS: t/spy-rm.tap 6 - rm -fr
--8<---------------cut here---------------end--------------->8---

There’s no /bin/rm in Guix build environments, hence the message (in
fact, there’s no /bin at all.)

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.

Would it be possible to change these tests to use ‘rm’ instead of /bin/rm?
What do you think?

Thanks,
Ludo’.

Message #8 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: Sun, 29 Dec 2013 23:17:20 +0100

tags 16291 notabug
close 16291
stop

On 12/29/2013 10:49 PM, Ludovic Courtès wrote:
> Hello!
>
> While upgrading the GNU system to Automake 1.14.1, I noticed that a few
> tests emit warnings like this:
>
SKIPs are not warning, just informative messages explaining why some
tests couldn't be run.

> --8<---------------cut here---------------start------------->8---
> SKIP: t/spy-rm.tap 1 # SKIP /bin/rm not found
> PASS: t/spy-rm.tap 2 - rm -f
> SKIP: t/spy-rm.tap 3 # SKIP /bin/rm not found
> PASS: t/spy-rm.tap 4 - rm -rf
> SKIP: t/spy-rm.tap 5 # SKIP /bin/rm not found
> PASS: t/spy-rm.tap 6 - rm -fr
> --8<---------------cut here---------------end--------------->8---
> 
> There’s no /bin/rm in Guix build environments, hence the message (in
> fact, there’s no /bin at all.)
>
This is not a problem, since our test is smart enough to skip the checks
that would require the non-existent /bin/rm program.

> 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?  If not, that would be a bug, and you'd be justified
to reopen this report).

> 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.

Thanks,
  Stefano

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

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

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?  Why
does /bin/rm matter in the first place?

Thanks for your quick feedback,
Ludo’.

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

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

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

Stefano Lattarini <stefano.lattarini <at> gmail.com> skribis:

> 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?

No; I’m asking because the tests specifically refer to /bin/rm.
What’s the reason?

Ludo’.

Message #24 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 23:01:43 +0100

On 12/30/2013 09:55 PM, Ludovic Courtès wrote:
>
> [MEGA-SNIP]
>
> No; I’m asking because the tests specifically refer to /bin/rm.
> What’s the reason?
>
Copying from my first reply:

    Ludovic Courtès wrote:
    > 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.

To reiterate, we want to find out about deficiencies in the "base
system" even if the user who is running the Automake testsuite has
mitigated them by installing better tools earlier in his PATH.

Regards,
  Stefano

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

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

Stefano Lattarini <stefano.lattarini <at> gmail.com> skribis:

> On 12/30/2013 09:55 PM, Ludovic Courtès wrote:
>>
>> [MEGA-SNIP]
>>
>> No; I’m asking because the tests specifically refer to /bin/rm.
>> What’s the reason?
>>
> Copying from my first reply:
>
>     Ludovic Courtès wrote:
>     > 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.
>
> To reiterate, we want to find out about deficiencies in the "base
> system" even if the user who is running the Automake testsuite has
> mitigated them by installing better tools earlier in his PATH.

OK, got it now.  Thanks for taking the time.

Ludo’.

Previous Next

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