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?

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.

Bob
-- 
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/