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

Hi,

Bob Friesenhahn <[email protected]> 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



_______________________________________________
Bug-libtool mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-libtool