[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.
Wed, 16 Jun 2021 16:25:53 -0400
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Bob Friesenhahn <email@example.com> writes:
> 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
> --version argument?
It seems to me that we are looking farther than needed; unless we have
good reasons not to (which we do not seem to have), it seems reasonable
to assume 'file' to be correctly working; if the user install a 'file'
command on their PATH which behaves differently than the traditional
'file' utility, they can only blame themselves for problems.
> 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.
For the non-FHS package managers such as Guix/Nix, that are able to run
on top of any GNU/Linux distribution, that would be sub-optimal as the
command would be used from the host instead of from the user's PATH;
e.g. if you 'guix install file', file wouldn't be used from Guix but
from the host distribution instead.
I hope that helps to understand the rationale for behind preferring PATH
to hard coded locations.