Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Tag functions with shell options?
- X-seq: zsh-workers 1516
- From: Anthony Heading <aheading@xxxxxxxxxxxx>
- To: schaefer@xxxxxxx
- Subject: Re: Tag functions with shell options?
- Date: Tue, 2 Jul 1996 23:27:35 +0100 (BST)
- Cc: aheading@xxxxxxxxxxxx, zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <960702143114.ZM5210@xxxxxxxxxxxxxxxxxxxxxxx> from "Bart Schaefer" at Jul 2, 96 02:31:10 pm
Bart wrote:
>
> } The lack of context was sort-of deliberate, since I
> } suspected any interest would be in the wider picture, rather than my
> } particular petty problems. It seemed simply an example of something
> } it would be nice to support elegantly.
>
> This introduces a whole class of problems, which is most obvious in the
> case when you *do not* know the names of the functions that should have
> their local options (or whatever) changed. In that case you almost end
> up needing something like Perl's "package".
Right. I guess this is like what I would have thought of doing as a sort of
closure. So a function, when defined, would snapshot its option-environment.
function setup() {
setopt local_options closure_options sh_word_split
. /someone/elses/setup/file.sh
}
> Because the alias for yfn was introduced *after* xfn1 was defined, xfn1
> still references the "real" yfn, rather than the alias. The presumption
> is that if you're going to use
OK. As if aliases are resolved at parse-time. Or something. Perhaps they are.
I should RTFS. But I understand now.
Thank-you all.
A
Messages sorted by:
Reverse Date,
Date,
Thread,
Author