Re: grep-2.5.1a egrep/fgrep PATH problem

[Charles Levert]

* On Friday 2005-06-24 at 11:32:25 -0700, Paul Eggert wrote:
> Charles Levert <address@hidden> writes:
> 
> > How about this, then?
> >
> > We store the grep executable as
> >
> >    /usr/libexec/grep/2.5.2/i686-pc-linux-gnu/grep
> 
> Yes, I thought of that solution this morning as I drove into work.
> (But you were faster.  :-)
> 
> Do we really need the version number?  Why not just install it as
> $(libexecdir)/grep/grep, say?

It doesn't cost much and the ability to have
several versions seem to be something people
want.  Granted, it's often non-free system grep
and GNU grep, but it could also be GNU grep-2.x.y
grep and an eventual innovative but little-tested
GNU grep-3.0.0.

You have edited out of your reply the
/bin/grep-2.5.2 suggestion.  The more I think
about it, the more I see an argument for keeping
under the file system /bin is on everything
that is needed for grep's basic functionality
(say the bare POSIX, non-GNU-extension stuff).

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.  Does /libexec
exist in general?  (I don't have access to
a bunch of different installed distributions
to check myself.)

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).  Mind you, we might just as
well assume that all this is the responsibility
of whomever invokes grep's configure, given
their system.


> Also, we should make a hard link from $(libexecdir)/grep/grep to
> $(bindir)/grep, falling back on a copy if the ln fails.  This will
> avoid one level of indirection in the common case of invoking plain
> grep.

Of course, a hard link is not possible if they
not even on the same file system.  I have
reservations with hard links (as opposed to
symlinks):

   -- When two hard-linked files are in different
      directories, sure you can see the link
      count being 2, but it's hard to find the
      sibling just by perusing the file system.

   -- When two hard-linked files live in the
      same directory, I have the following
      anecdote.  I use to install stuff something
      like this:

         cp .../build-dir-1.0/foo /usr/local/bin/foo-1.0
         chmod 755 /usr/local/bin/foo-1.0
         test -f /usr/local/bin/foo &&
            mv /usr/local/bin/foo /usr/local/bin/foo.old
         ln /usr/local/bin/foo-1.0 /usr/local/bin/foo

      Then, someday, another person with sysadmin
      power did something like:

         cp .../other/foo /usr/local/bin/foo

      I no longer had the build-dir because of
      tight space constraint, but I thought I
      was safe because /usr/local/bin/foo-1.0
      would still contain a copy of my version.
      Wrong!  Both /usr/local/bin/foo and
      /usr/local/bin/foo-1.0 were very much still
      hard-linked to the same original inode,
      only with the new content.

      Since then, because of this, I have moved
      to a symlink solution:

         cp .../build-dir-1.0/foo /usr/local/bin/foo-1.0
         chmod 755 /usr/local/bin/foo-1.0
         test -f /usr/local/bin/foo &&
            mv /usr/local/bin/foo /usr/local/bin/foo.old
         ln -s foo-1.0 /usr/local/bin/foo

      I wasn't in charge of backups and we didn't
      have reliable ones.

      I think foo-1.0 was in fact the main
      executable for emacs-18.58 (look ma, no
      configure), if memory serves me correctly.
      That used to take a long time to compile,
      as I'm sure you can well remember, so I
      was pretty PO.

      The same consequence could have happened
      with symlinks, but there somewhat more in
      your face and more explicitly remind anyone
      playing with the system that they have to
      copy their new stuff to a versioned file
      first, then change the symlink for the
      main name if appropriate.

When symlinks are not available (SysV < R4?),
I do prefer hard links to copies.


> I like this idea.  If there's no objection, I'll write up a patch that
> does this.

Go right ahead!  We can always iron out any
issue once there is actual code.