Re: grep-2.5.1a egrep/fgrep PATH problem

[Charles Levert]

* 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).