Zsh Mailing List Archive
Messages sorted by:
Re: Associative arrays and memory
- X-seq: zsh-workers 4634
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxxxxxxxxxx (Zsh hackers list)
- Subject: Re: Associative arrays and memory
- Date: Sat, 14 Nov 1998 10:47:19 -0800
- In-reply-to: <9811141526.AA19988@xxxxxxxxxxxxxxxxx>
- References: <9811141526.AA19988@xxxxxxxxxxxxxxxxx>
On Nov 14, 4:26pm, Peter Stephenson wrote:
} Subject: Re: Associative arrays and memory
} "Bart Schaefer" wrote:
} > zagzig<17> HISTSIZE=1000
} > zagzig<18> HISTSIZE=0 echo hello
} > hello
} > zagzig<19> echo $HISTSIZE
} > 2
} This seems to be OK after restoring the old behaviour, so I haven't
} look further into what had gone wrong.
I found it ... the assignment "pm = tpm;" was mistakenly deleted from
below the code that was replaced by the call to copyparam(). That is,
in save_params() in exec.c, it should look like
tpm->nam = s;
pm = tpm;
So copyparam() itself is OK.
} > } There are currently no special assoc arrays, of course, and it should
} > } probably be possible to prevent there being any
} > What about the discussion that started all this -- using an associative
} > array to give user access to shell-internal completion data?
} Rats, I just looked at zle_params.c and you're right --- they're
} marked special.
Of course, a non-special associative array can contain special parameters.
That was part of the idea of using a parameter hash as the implementation.
And that would be the way to do it, rather than make the associative array
} That doesn't mean assoc arrays need to be the same, though. The case
} that needs worrying about is the following:
} hash=(?...?) builtin_or_func
} where the ?...? represents whatever we pick for whole array
It doesn't matter that a whole array is being assigned to the hash, does
it? Even creating a scalar with the same parameter name would require
that it be saved/restored.
Or are you talking *about* special parameters within the associative array
that need to be saved, and that's why whole-array assignment would matter?
} There's also no problem if the hash is simply used for storing
} information and is not tied to special variables or functions. You
} only need a special mechanism for restoration for something like
} $path, where there's an internal variable that needs setting; simply
} restoring the struct param won't do that.
That is, you need to call the pm->sets functions when restoring specials,
which is what restore_params() does. But my implementation does not call
anything equivalent to restore_params() on the parameter table stored in
the association, so it isn't helping to have save_params() copy it in the
} If we can agree that use of
} assoc arrays is simply going to be by direct access to the parameter
} we can avoid ever copying it: the above shell pseudocode simply makes
} the supplied $hash available for the duration of builtin_func.
I'm not entirely sure what you mean about "direct access." If we're
going to put stuff like the present $BUFFER into an association, it needs
to be the case that assignment to (say) zle[BUFFER] actually modifies the
line editor state.
So the question is, should it ever be the case that
zle=(? BUFFER "this is the command line" ... ?) builtin_or_func
causes the old command line to be restored following builtin_or_func?
And if we save and restore such a hash by the simple stacking method, is
$zle[BUFFER] going to give the right thing after builtin_or_func?
Bart Schaefer Brass Lantern Enterprises
Messages sorted by: