quilt-dev
[Top][All Lists]
Advanced

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

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


From: Gary V. Vaughan
Subject: Re: [Quilt-dev] [PATCH] user-definable tail and grep
Date: Fri, 16 Sep 2005 00:21:11 +0100
User-agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)

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"...

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'.

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

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"}

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!

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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