Re: [Help-bash] make function local

[Chet Ramey]

On 4/12/15 5:56 PM, Eduardo A. Bustamante López wrote:
> Oh, you already have lots of things to do to bother with this :-)
> 
> Anyways, I'll expand them.
> 
> On Fri, Apr 10, 2015 at 04:35:25PM -0400, Chet Ramey wrote:
>> On 4/10/15 10:13 AM, Eduardo A. Bustamante López wrote:
>>
>>> - a faster implementation of the variable lookup code
>>
>> What does this mean, exactly?  Optimizing the existing code paths? (Have at
>> it.)  Different semantics?  Static as opposed to dynamic scoping?
> 
> Yes. I've been using gprof to study the code paths of some basic functions, 
> and
> it seems like it spends quite some time in the find_variable() and related
> functions (IIRC, there was an mt_hash or something function taking up some
> precious time). I'm not sure if it might be better to have other kind of data
> structure for this. TBH, I'm not sure if there's even enough justification for
> this, other than to make bash startup faster.
> 
>>> - a shopt to disable evaluation of shell code in places like arithmetic
>>> expansion
> 
> Remember this thread?
> http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00158.html

Sure, of course.  Here's how I summarized the concern:

"assignment statements in arithmetic expressions
that contain array references are also word expanded, almost as if they
were executed in an assignment statement context"



> 
> At one point, this was brought up:
> 
> dualbus@hp ~/t % bash -c 'var="a[\$(ls)]"; a=(); a[var]=x; declare -p a' 
> bash: bar baz foo: syntax error in expression (error token is "baz foo")
> 
> I understand the reasons behind it. This time I don't want to debate that :-)
> But, wouldn't it be nice to have a `arith_expand' or something shopt that when
> turned off, this happened:

OK, but you're going to have to specify it more tightly than that.  The
first question is how bash treat tokens that look like identifiers in
arithemtic expression contexts: do you treat them as variables that may
specify expressions, or do you treat them as variables whose values must
be integer constants?  Then you have to specify which word expansions
you'd like expressions to undergo, and which word expansions you'd like
array subscripts to undergo in case they're different, and in which
contexts you'd like that to happen.

The answer to the first question should determine whether and why

a[var]=x

and

a[a[\$(ls)]]=x

from your example should behave differently.

Or is it some middle ground you want: that identifiers are expanded and
the expanded values are treated as expressions, but those expressions
don't undergo any word expansions.  That still leaves the question of
what to do about array subscripts in these expressions.

That should be enough to get a discussion started.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/