On Tue, 2 Sep 2025, 23:45 Koichi Murase, <myoga.mur...@gmail.com> wrote:
> I think, if an option to change the language behavior would be
> introduced, the option should be implemented as ``a file-local option
> that applies to shell codes based on lexical scoping''.
>
I really like this approach, but I suspect it will lead to a need for
something akin to Perl's "use" or "BEGIN" keywords to execute code as soon
as they're fully parsed, even if the encoding block hasn't finished parsing.
Then we could write something like this:
>>MyLib.bash<<
shopt -s lexical
myfunc() {
BEGIN { shopt -s extglob; }
echo *(.)foo # safe because « shopt -s extglob » runs before parsing
this line
}
Admittedly extglob isn't an ideal example, since in practice one would just
set it at the file level, but I'm trying to illustrate how it could change
a setting during parsing.
options to change
> the behavior should affect only the code in the same file where the
> option is set.
Question: if file A sources for B, and file B sources file C, but only file
B indicates it expects lexical option scoping, should file A and file C see
each other's changes?
While we're at it, please can we have lexically scopes variables in
functions? Should bash then mimic ksh, treating "function foo" as requiring
lexical scoping, but leaving "foo()" with old-style (dynamic) scoping?
A non-trivial question is how to represent `the embedded options'
> within the output of `declare -f funcname' or `type funcname' or `bash
> --pretty-print' so that they can be eval'ed later.
Maybe « function foo -o compat=60 -o extglob -o nullglob … { …; } »?
Not sure whether I prefer -o/+o or -s/-u
». Note that in this example, one needs to explicitly unset an option
> `zzz' by `+o zzz' because `zzz' might be turned on in the context
> where `eval' is performed.
>
With « -o compat=60 » in my example we then only need a list of options
that don't match, rather than all of them.
-Martin
