[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file' on GNU
From: |
Ludovic Courtès |
Subject: |
bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file' on GNU systems. |
Date: |
Tue, 24 Jun 2014 16:37:23 +0200 |
User-agent: |
Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux) |
Bob Friesenhahn <address@hidden> 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’.