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

From: [email-masked] (Ludovic Courtès)
Date: Tue, 24 Jun 2014 16:37:23 +0200

Bob Friesenhahn <[email-masked]> skribis:

> On Mon, 23 Jun 2014, Ludovic Courtès wrote:
>
>> Hello,
>>
>> The patch below changes occurrences of ‘/usr/bin/file’ to just ‘file’.
>>
>> The impetus is that on systems using GNU Guix, NixOS, GoboLinux, and
>> others, the ‘file’ command is not available as /usr/bin/file, so it must
>> instead be taken from $PATH.
>>
>> (I conservatively left ‘/usr/bin/file’ for more centralized systems such
>> as BSD, IRIX, etc. where it’s more likely to be a valid command.)
>
> Were you able to re-test on all of the impacted platforms?

No, but that list is verrry long.

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

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.

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.

WDYT?

Thanks,
Ludo’.