2025年8月31日(日) 0:45 Stan Marsh <gaze...@xmission.com>:
> However, it does still leave the problem that whatever objections they have
> had to the
> idea of doing it with "shopt" applies to pretty much most/all of the (other)
> "shopt"
> options. That is, most/all of the "shopt" options change shell behavior in
> ways that
> can impact existing code and/or libraries.
>
> This is why, despite the fact that a lot of the "shopt" options look
> interesting - and
> basically correct for longstanding bugs^Wquirks in the shell language - I
> have shied
> away from using "shopt" much. Using them is going to basically require you to
> re-analyze every bit of existing code, as well as, of course, any
> libraries/frameworks
> that you are using. It almost always ends up not being worth the
> trouble/risk.
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''.
Something like `local -' (for shopt) isn't sufficient for options that
modify the language behavior dynamically. To be safe, ALL functions
need to declare `local -' and adjust dozens of options at the
beginning, or otherwise, it can be affected by dynamic settings set by
the caller.
Instead, behavior-modifying options should apply lexically, i.e., the
behavior should be determined by the set of option values *when the
shell construct is parsed*, which means that the relevant option
values are embedded within an AST. In addition, the options to change
the behavior should affect only the code in the same file where the
option is set. For example, an option X turned on in file "A.sh"
shouldn't affect the behavior of "libB.sh" sourced from inside file
"A.sh", and the same rule needs to apply to the nested source
recursively.
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 it can be
represented in a similar way as the trace attribute of the function;
i.e., « funcname() { ...; }; declare -f -o xxx -o yyy +o zzz funcname
». 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.
--
Koichi
