[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: grep-2.5.1a egrep/fgrep PATH problem
From: |
Charles Levert |
Subject: |
Re: grep-2.5.1a egrep/fgrep PATH problem |
Date: |
Fri, 24 Jun 2005 20:30:01 -0400 |
User-agent: |
Mutt/1.4.1i |
* 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.
- Re: grep-2.5.1a egrep/fgrep PATH problem, (continued)
- Re: grep-2.5.1a egrep/fgrep PATH problem, Charles Levert, 2005/06/23
- Re: grep-2.5.1a egrep/fgrep PATH problem, Paul Eggert, 2005/06/23
- Re: grep-2.5.1a egrep/fgrep PATH problem, Tony Abou-Assaleh, 2005/06/24
- Re: grep-2.5.1a egrep/fgrep PATH problem, Paul Eggert, 2005/06/24
- Review Process [was: grep-2.5.1a egrep/fgrep PATH problem], Tony Abou-Assaleh, 2005/06/24
- Re: grep-2.5.1a egrep/fgrep PATH problem, Charles Levert, 2005/06/24
- Re: grep-2.5.1a egrep/fgrep PATH problem, Charles Levert, 2005/06/24
- Re: grep-2.5.1a egrep/fgrep PATH problem, Tony Abou-Assaleh, 2005/06/24
- Re: grep-2.5.1a egrep/fgrep PATH problem, Charles Levert, 2005/06/24
- Re: grep-2.5.1a egrep/fgrep PATH problem, Paul Eggert, 2005/06/24
- Re: grep-2.5.1a egrep/fgrep PATH problem,
Charles Levert <=
- Re: grep-2.5.1a egrep/fgrep PATH problem, Bob Proulx, 2005/06/26
- Re: grep-2.5.1a egrep/fgrep PATH problem, Bob Proulx, 2005/06/26
- Re: grep-2.5.1a egrep/fgrep PATH problem, Charles Levert, 2005/06/23
- Re: grep-2.5.1a egrep/fgrep PATH problem, Paul Eggert, 2005/06/24
- Re: grep-2.5.1a egrep/fgrep PATH problem, Tony Abou-Assaleh, 2005/06/24
- Re: grep-2.5.1a egrep/fgrep PATH problem, Andreas Schwab, 2005/06/24
- Re: grep-2.5.1a egrep/fgrep PATH problem, Paul Eggert, 2005/06/24