[Top][All Lists]

[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:

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]