bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grep-2.5.1a egrep/fgrep PATH problem


From: Bob Proulx
Subject: Re: grep-2.5.1a egrep/fgrep PATH problem
Date: Sun, 26 Jun 2005 18:26:55 -0600
User-agent: Mutt/1.5.9i

Charles Levert wrote:
> The problem is that I don't see a /libexec
> directory on my system; I want to avoid the
> /bin + /usr/libexec combination, since they may
> be on different file systems.

A good concern.  It might be on different systems and it would be
nasty to have /bin depend upon /usr when it might not be mounted yet.

> Does /libexec exist in general?  (I don't have access to a bunch of
> different installed distributions to check myself.)

I don't know of a system in which it exists.

> I consulted
> 
>    <http://www.pathname.com/fhs/pub/fhs-2.3.html>
> 
> but there is no mention of libexec, nor of grep
> for that matter (although it has a minimal list
> of /bin programs).

The location of grep has been one of those long standing differences
between systems.  On some systems it is in /bin (e.g. Debian, Red Hat)
and on others it is in /usr/bin (e.g. OpenBSD, AIX).  Some commercial
systems (e.g. HP-UX) take the (in my mind confusing to the user) step
of symlinking /bin to /usr/bin so that all binaries appear to be in
both locations.  Some systems maintain two directories but symlink
programs from one to the other.  I believe one should never hard code
the path to grep.

The one good thing about having binaries in different locations is
that people who hard code paths to binaries (e.g. /usr/bin/grep)
usually get their justice for it as soon as they try to move to
another system.  The one bad thing is that frequently it is an
innocent code porter who suffers the consequences.

> Mind you, we might just as well assume that all this is the
> responsibility of whomever invokes grep's configure, given their
> system.

It has been a long standing understanding that the GNU system is not
governed by the FHS.  Therefore GNU Makefiles, such as GNU automake
generated Makefiles, do not need to conform to the FHS.  Instead they
should conform to the GNU standards and guidelines.  Packagers of
projects for other software distributions will need to perform
whatever fixup they need when they package.

On the surface this sounds like a harsh statement.  But in practice it
works out quite well and is actually very easy for packagers of
software distributions handle.  Because GNU Makefiles are very regular
this makes a nice expected behavior that is easy to understand and
easy to work with.  Check that link you posted earlier for one
example.

> http://cvs.fedora.redhat.com/viewcvs/devel/grep/grep.spec?annotate=1.50

After the 'make install DESTDIR=/some/stage/area' they move the
binaries from /usr/bin to /bin and other fixup to match their distro
policy.  This is all fine and good.  Other distros all do something
similar with their packages, not just grep.  GNU coreutils in
particular has many requirements placed upon locations by the FHS and
packagers must move parts here and parts there to comply.  I package a
lot of GNU software for other systems and making these movements to
comply with local system policy is easy and not a problem.

Bob




reply via email to

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