* On Friday 2005-06-24 at 05:49:24 -0300, Tony Abou-Assaleh wrote: > Are assuming that grep will be "installed"?
For the main grep binary to work? No. It still would have no hardcoded path. It just wouldn't support adjusting its behavior according to the name under which it was invoked. For the purpose of these wrapper scripts? Yes. They are a convenience of an automated installation process (and of a non-interactive configure process; compare with Perl/metaconfig's humorous Configure, in its default mode). Users who move stuff around can still write their own wrapper scripts; and, they have the advantage of knowing the peculiarities of their target platform then. > It is often not > the case, especially in academic places on big unix server that have a > default unix grep. I am familiar with that academic situation. The main reason for providing fgrep and egrep is at the system level. Manual users can just learn to call grep with -F or -E, but existing software may use them by name and expect them to be in the default PATH, so, for compatibility's sake, it wouldn't be reasonable to not provide them on a system. Just like it wouldn't be reasonable to not have /bin/sh or /bin/csh, although they usually almost are symlinks to something else these days; they are rarely, if ever, the originals. > I know one could use the --prefix with configure, and that's something > that we should incorporate into these scripts (if it's not already), What I proposed a few emails ago uses $bindir and $transform, which come from configure. > but > in many cases, one simply copies the binaries to a convenient location > (e.g., if you don't care about the man pages and stuff). Only for smallish programs that don't have to access their own library-type stuff; e.g., "/usr/share/emacs/21.4". Otherwise, you better use --prefix=$HOME if your disk quota permits it, or else convince your sysadmin to properly populate /usr/local (or /opt or /usr/gnu or whatever). > There seem to be good arguments for both multiple binaries and for > wrappers, which all points to the fact that we should be offering the user > the option. I like the wrapper idea for system-wide installs, but prefer > the binaries for manual installs (especially on solaris). On a PC, disks and memory are so huge these days that the extra space for the binaries doesn't matter much for a program the size of grep. But there are other smaller platforms, still bigger than those that must absolutely use something like busybox, that can benefit from the saving in space. We could also move the main parts of grep in a shared library, to be used by small {,f,e}grep executables, but we would then loose its standalone nature. Mind you, we already lose that when we link (dynamically) against libpcre.so rather than only load it on demand; this can push libpcre.so in /lib instead of /usr/lib when grep is in /bin. Loading on demand will have to be considered at some point if we ever want to provide libz.so and libbz2.so support, like some distributors do, because the grep executable must remain somewhat small and independent (when without the extensions).