Re: [Quilt-dev] [PATCH] user-definable tail and grep

[Andreas Gruenbacher]

On Friday 16 September 2005 01:21, Gary V. Vaughan wrote:
> Hallo Andreas,
>
> Andreas Gruenbacher wrote:
> > On Friday 16 September 2005 00:05, Gary V. Vaughan wrote:
> >>The normal approach is to allow the script user to override paths to
> >>particular commands in the environment.  I was quite surprised to
> >>see @COMMAND@ substitution hard coding scattered across the code rather
> >>
> >>than something like this at the top of patchfns:
> >>: ${TAIL="@TAIL@"}
> >>
> >>Then for the rest of the scripts:
> >>
> >>"$TAIL" -n 42 ...
> >>
> >>Is this just an oversight?  Or is there a reason for that design?
> >
> > What's the benefit of "$TAIL" over @address@hidden (I'd rather use $TAIL 
> > without
> > quotes to allow passing in arguments/etc, too.) IMHO it's a mess either
> > way, and once we have @FOO@ substitutions we can as well replace them all
> > over the place.
>
> Flexibility at runtime.  The quotes are a red herring -- but helpful to
> people who installed tail to "C:\Program Files\GNU Tools\tail"...

One mor reason to use the PATH approach.

> Users can change the tools that they use.  Say my sysadmin has installed
> the gnu utils in /opt/gnu (as cp, date, getopt etc) and I don't want to
> use them by default by changing my path, but know that quilt relies on
> them... I can 'export DATE=/opt/gnu/bin/date', and then I notice that
> /opt/gnu/bin/getopt isn't a new enough version, so I build the latest in
> my home directory and 'export GETOPT=$HOME/bin/getopt'.

Then you'd have to set up your environment specifically for quilt. A weird 
idea.

> It's easy to test with different dependent tools without building quilt
> all over again.

Good point.

> I could probably think up more, but I'm sure you get the idea.  All the
>
> (large!) shell scripts I've ever seen start with a list of commands as:
> : ${COMMAND="default"}

Makes more sense than a new PATH component for an isolated script, yes.

> Normally the defaults don't hard code a path, they assume that the user
> will already have set the PATH environment up to find something useful,
> and will export appropriate variables at runtime if not.
>
> Additionally, since the substitutions are done by configure, the
> defaults can be handled intelligently.  A contrived example: Checking
> for GNU grep, then /usr/xpg4/bin/grep, and defaulting to those if
> found or else showing a warning at the end of the configure run that
> no suitable grep was found and the PATH will be searched at runtime.
>
> > On the other hand, adding a directory to the front of path in patchfns
> > would allow us to get rid of most @address@hidden in the scripts.
>
> That too!

Thanks,
Andreas.