Re: problem with egrep and fgrep

[Bob Proulx]

Ralph Corderoy wrote:
> Bob Proulx wrote:
> > I often use tools installed on an NFS server on an NFS client.  Others
> > use tools on AFS clients where the install path is not the same as the
> > usage path.
> 
> So how do you cope with programs that need to know where to find
> run-time resources at compile time, e.g. perl.

I don't think that is a good comparison.  Perl is a complete subsystem
and has always been that way.  There are many files installed as a
set.  It is not reasonable to expect that a copy of '/usr/bin/perl'
and nothing lese to another location would work by itself.  It needs
to find its support files.[1]

But for 'egrep' and 'fgrep' it used to be that those were their own
standalone programs each implementing their own unique type of RE
automaton.  If you copied 'egrep' from one place to another it still
worked the same.  But in the current implementation 'egrep' and
'fgrep' now depend upon a separate 'grep'.  Now 'egrep' and 'fgrep'
need their "support subsystem".  That is a change from traditional
behavior that tripped up the original poster.

However the ways that egrep need to be called in order to trip someone
up are ways that are best not used.  IMNHO it appears to me that you
can only break something which is already fragile/broken such as by
using a full hard coded path instead of finding the binaries on PATH.
That is why I previously suggested that if PATH cannot be changed that
the end user name the programs uniquely.  Using full hard coded paths
is just a bad practice.  So the current implementation which calls
'grep' in a script is really not so bad all in all.  Pretty much no
matter what you do there will be tradeoffs.

Bob

[1] Actually I do run perl from the NFS server for our own EDA/CAD
tools.  I use a wrapper script which passes '-I /path' options to the
real perl.  (Write me if anyone is interested.)
The problems this solves are 1) Developers using SWIG to compile
modules into perl.  In that case the version of perl is bound and one
cannot use random different versions which might be installed on
different systems.  And 2) Developers using modules which may not be
installed on all systems.  By loading from a central location such as
NFS everything that is needed is there and the application will run on
any of the systems in our compute pool.