On Fri, 14 May 2010 11:24 +1000, "Andrew Clarke" <[email protected]>
wrote:

> Until I learn the power and weakness of (( )) I won't know when to use 
> it. I literally haven't used it in the 15 years I've been using ksh. I 
> do think I'm overdue.

If you've never used (( )) before, you're right.  It *is* a bit overdue
:-)

> > As usual, it would be good to know the context; what is
> > the problem you're trying to solve?
[ ... ] 

> I need to check it's talking to a terminal because this is a function 
> for programmers off the command line but it is also used in cron scripts 
> to pick settings. If it's not a terminal then it has to be quiet and not 
> prompt for things.

Sounds familiar...  The trick with that is to create a function that 
either performs all the interaction *or* returns the defaults if no
tty is present.

> > We're still left with '$list' and if the only possible values
> > are '' or 1, I guess it is not properly named.

> It's assigned from a -l option off the command line, and I admit it is 
> badly named. My usual convention is different. This flag requests a 
> listing of certain items.

I recently developed a bit of personal idiom that uses (( )) exactly for
this purpose.  I make it a habit to set defaults for any possible
option settings.  For a truth value, the default would be '0', and '1'
otherwise.

The code below relies on the implicit recursive arithmetic in (( ))
which goes at least 6 or 7 levels deep.


# ----8<---- snip -----8<----
readonly on=1 off=0 yes=1 no=0 true=1 false=0

opt_l=false

while getopts l c; do
case $c in
( l ) opt_l=true ;;
( * ) print "usage: ... "
esac
done
shift $((OPTIND-1))
   .
   .
   .

((opt_l)) && ...

# ----8<---- snip -----8<----


I once created a small ksh framework for generating option lists and 
the corresponding while/case/ shift, but I must have lost the code.

  option <char> [ --<longopt> ] [[optvar]=[default]] "option usage ..."

would be invoked repeatedly,

  parse_options 

would close the option list and do the final processing.

Cheers,

Henk
-- 
e "Henk Langeveld" <[email protected]>

_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users

Reply via email to