GNU bug report logs - #17840
[PATCH] libtool: Use 'file' instead of '/usr/bin/file' on GNU systems.

Previous Next

Full log

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: mhw <at> netris.org, Ludovic Courtès <ludo <at> gnu.org>,
 17840 <at> debbugs.gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of
 '/usr/bin/file' on GNU systems.
Date: Wed, 16 Jun 2021 16:25:53 -0400

Hi,

Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us> writes:

> On Tue, 24 Jun 2014, Ludovic Courtès wrote:
>>
>>> The reason for the hard-coded path is because there are a number of
>>> different 'file' programs and libtool expects particular output from
>>> the 'file' program that it uses.  If the 'file' encountered via PATH
>>> is not the same as the common one available as ‘/usr/bin/file’ on GNU
>>> systems, then there would be a problem.
>>
>> Well, the systems I was referring to are GNU systems too.  ;-)
>>
>> Do you remember what other ‘file’ programs could interfere?  Debian has
>> only one ‘file’ program, for instance:
>> <https://packages.debian.org/search?searchon=contents&keywords=file&mode=exactfilename&suite=stable&arch=any>.
>
> This is the web page for the most popular and common 'file'
> command. It is not a GNU program:
>
> 	http://darwinsys.com/file/
>
>> Besides, relying on file names to identify programs seems fragile: just
>> like I can have an unrelated ‘file’ command in $PATH, I can install an
>> unrelated ‘file’ command in /usr/bin.
>
> Yes, it is fragile but it is more likely to encounter a wrong program
> named 'file' in the path than to encounter a wrong /usr/bin/file
> program.
>
>> If there’s a concrete risk of confusion with a same-named program,
>> perhaps the most robust thing to do would be to try, say, ‘file
>> --version’ and search for some distinguishing pattern in the output.
>
> What would we do if 'file' did not respond appropriately to a
> --version argument?

It seems to me that we are looking farther than needed; unless we have
good reasons not to (which we do not seem to have), it seems reasonable
to assume 'file' to be correctly working; if the user install a 'file'
command on their PATH which behaves differently than the traditional
'file' utility, they can only blame themselves for problems.

> A simple approach would be to use /usr/bin/file if is available, or
> otherwise use the first 'file' found in the executable search path.
> This avoids the need for re-testing on exotic systems and does not
> substantially increase the level of risk.

For the non-FHS package managers such as Guix/Nix, that are able to run
on top of any GNU/Linux distribution, that would be sub-optimal as the
command would be used from the host instead of from the user's PATH;
e.g. if you 'guix install file', file wouldn't be used from Guix but
from the host distribution instead.

I hope that helps to understand the rationale for behind preferring PATH
to hard coded locations.

Maxim

Previous Next

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