Re: special/readonly variables in sh emulation

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Bart wrote:
>
> } Should we allow attributes like uppercase and integer to apply across
> } an array like in ksh (this is messier for hashes as each element has
> } its own param)?
> 
> I don't know what the ksh implementation of this is like -- does it apply
> the conversion at fetch time, or at assign time?

Assign time it seems - fetch time would be better in my opinion. The
ksh feature which I was refering to and which I like is:
  $ a=(one two three)
  $ typeset -u a
  $ echo ${a[@]}
  ONE TWO THREE
And similarly for other typeset options such as -i.

And thanks for answering the various questions.

> The way I would structure this is:
> 
> The lowest-level API provides functions to set and get scalars (strings,
> ints, etc.), arrays, array elements, and associative array elements
> (including getting the keys or values).
> 
> An intermediate API provides functions implemented in terms of the above
> to set and get string ranges, array slices, and arrays of associative
> array elements.  Special parameters have the option of implementing only
> the lowest-level API and using the functions from the intermediate one,
> or of providing the intermediate ones for efficiency or other effects.

Ok, that is roughly what the patch I posted was heading towards though
I'm entirely happy with it. To support the specials overriding the
intermediate API you get a fairly big method table. Simple specials
would use the default methods. Unless anyone can think of a better
system than the method tables or come up with a better, more generic
version of the paramdef struct system for setting up specials?

> The complication arises when we add in nested substitutions, where the
> result of an inner substitution has to be treated as a parameter value
> for purposes of outer substitutions.  I suggest we actually create a
> dummy parameter in this case rather than trying to handle everything via
> manipulation of the Value structure -- but that means some pretty heavy
> rewriting of paramsubst() and getarg().

A dummy param might be good. I was sort of hoping to get rid of the
value struct and use start/end ints where necessary but another option
might be a dummy param there to.

> If we did create a dummy parameter, we could even give it a name and
> let the surrounding substitutions refer to it explicitly, e.g.:
> 
> 	... ${$(some command):+blah blah $_ blah blah} ...

That's an interesting idea.

> I haven't looked at your patch in detail yet, but these seems like things
> that could go in the optional intermediate-level API.

It would be useful if someone could look at it just a little bit. What
I'm least sure of is what is needed to support associative specials
properly.

I've not done anything on this since last week - I was away for the
Easter bank holidays.

Oliver

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.