* On Friday 2005-06-24 at 11:32:25 -0700, Paul Eggert wrote: > Charles Levert <[EMAIL PROTECTED]> 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.
