[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
bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file' on GNU systems.
Tue, 24 Jun 2014 11:28:25 -0500 (CDT)
Alpine 2.01 (GSO 1266 2009-07-14)
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:
This is the web page for the most popular and common 'file' command.
It is not a GNU program:
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
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
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.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/