Re: Notes on bash(1)

[Peter Stephenson <pws@ibmth.df.unipi.it>]

Phil Pennock wrote:
> * bash has arrays.  'declare', 'local' & 'readonly' each accept '-a' to
>   declare an array.  Is it reasonable to add '-a' to 'typeset'?  This
>   would automatically duplicate the bash-ism.

It's not exactly essential, since bash and zsh have rather different
extensions to sh in any case.  They're only similar in as much as they
both include sh.  It's hard enough keeping ksh emulation working.

>   Further, would it be an idea to then deprecate 'set -A' which
>   overloads parameter setting onto 'set'?

That's needed for ksh.

> * ${parameter/pattern/string} and ${parameter//pattern/string}
>   pattern is expanded as per pathname expansion.  Longest match of
>   pattern against parameter is replaced with string.  Once for / and for
>   all instances with //.  #pattern anchors to beginning, %pattern
>   anchors to end.  string may be null.  Applied to an array, this works
>   on each element.
>   zsh has a some of this with the colon-modifier 's'.

This would be quite useful, since :s only does simple string
replacement, and it doesn't clash with anything, yet, though if you
wait long enough...

Maybe it can be done quite simply by upgrading the extra flags Sven
added for # and % to match internal bits of a parameter's value.

>   The anchors in particular are nice.  They would make it easy to fully
>   replicate basename(1) without forking.  We can't currently (AFAIK)
>   accurately duplicate $(basename file .ext) (think - filename: .ext.ex)
>   % base=${var:t:s/%.ext//}

If you mean `remove the extension if and only if it's .ext', then you
can do ${${var:t}%.ext}.

> * ${parameter:offset} and ${parameter:offset:length} provide substring
>   and array extraction.  Both length and offset are arithmetic
>   expressions.  length>=0.  offset may be negative to measure from end.
>   zsh notably has ${parameter[start,stop]} already.  How desirable is
>   this alternate syntax, given that zsh allows history modifiers in the
>   same place?  It doesn't look like there would be a conflict, provided
>   zsh requires $[...] for variables there.  Testing, bash allows:
>   $ foo=abcde; t=2; echo ${foo:t}

I think it's too close to the history modifiers and we'd better stick
with the subscript notation, unless we're aiming at a bash
compatibility mode which is really going a bit far.

It worries me slightly that there are people out there who don't know
the difference between bash and sh --- which is their problem, but one
day they may start inflicting it on other people.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy