bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem with egrep and fgrep


From: Bob Proulx
Subject: Re: problem with egrep and fgrep
Date: Mon, 13 Sep 2004 13:48:10 -0600
User-agent: Mutt/1.3.28i

Paul Jarc wrote:
> I disagree, but how's this for a compromise - look first in @bindir@,
> and then in $PATH:
> 
> #!/bin/sh
> grep=`PATH='@bindir@':$PATH which grep` || exit 2

'which'!  That opens another Pandora's box of problems.

The classic 'which' is a C-shell script which loads ~/.cshrc.  On
newer systems 'which' is frequently a /bin/sh script.  Sometimes a
/bin/bash script.  There is no portable way to use 'which'.

If you can tolerate extensions then 'command -v' or 'type' or 'whence'
are possibilities.  But none are completely portable.  None are POSIX
standard.

This reference is useful for discussion here:

  
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-debian-maint-scripts

In it the following is suggested as the best method to find a command
on PATH.

     pathfind() {
         OLDIFS="$IFS"
         IFS=:
         for p in $PATH; do
             if [ -x "$p/$*" ]; then
                 IFS="$OLDIFS"
                 return 0
             fi
         done
         IFS="$OLDIFS"
         return 1
     }

> case $grep in
>   /*) exec "$grep" -E ${1+"$@"};;
>   *) echo "$grep" >&2 && exit 2;;
> esac

Since 'grep' has no subprocesses it would seem simpler, if that is
what you want to do, to just to set PATH to '@bindir@':$PATH and then
execute grep without trying to locate it first.

> Or something similar.  (On NetBSD, "which" prints errors to stdout and
> still exits 0.)

Argh!

Bob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]