rethinking typeset -g

[ormaaj]

I have discovered that I made possibly important mistakes during my initial recommendation to adopt the typeset -g feature that could implicate future directions.

First a correction - the origin of -g was actually zsh, where it serves as a means of setting attributes without localizing variables as a side-effect. That differs from my initial analysis where I determined its purpose was for leapfrogging all the local scopes (in a dynamic scoping context) to set the real global unconditionally. That fact somehow eluded whatever research I did at the time.

In reality, it was bash that effectively misimplemented the zsh feature in that way. (I didn't ask whether it was deliberate but it doesn't really matter). It appears that bash 5.3 intends to remediate that by adding a -G option that follows the zsh / mksh semantics (currently undocumented, it was also an undocumented synonym for -g prior to the new 5.3 behavior).

At the time I presented -g as a minor convenience feature, which brings me to the other important consideration - I failed to foresee the significance of that feature in combination with @mirabilos special ${|;} substitution in mksh ("funsub" in bash jargon). Unlike typeset -g in isolation, it is clear ${|;} imparts an important addition to the language. I've gotten pretty good at using it in experimental versions of all 3 implementations at this point. It really does force a rethinking of ones approach to all manner of things.

So these facts together pose a dilemma. The original zsh formulation of typeset -g turns out to be super important for allowing typeset to modify function-local variables from within ${|;}, or outer scopes in contexts where they are nested, and the "bash flavored" -g is clearly in conflict. It made sense for ksh93 due to its natural compatibility with static scope and still has some interesting niche uses of its own. Meanwhile ${|;} in ksh93 presumably would depend on future dynamic scope support, and likely modifications / enhancements to facilitate static scope and other details.

I'm not sure what the best move is. An option would be to just remove -g until dynamic scope is figured out so the more useful and interoperable variant can be correctly implemented. Or maybe move it to some other non-conflicting option name for now and leave it undocumented. I don't see any perfect solution in light of bash basically having -g and -G "backwards" and no good way to correct for it.

Very interested in others thoughts about this.

[mirabilos]

On Sun, 18 May 2025, Daniel Douglas wrote: Very interested in others thoughts about this.

“typeset -g” in mksh originated as new builtin named “global” which was later renamed (much before funsubs and valsubs). It was specifically designed to access the parent scope and thus indeed is no good match for AT&T ksh’s static scoping. bye, //mirabilos -- <igli> exceptions: a truly awful implementation of quite a nice idea. <igli> just about the worst way you could do something like that, afaic. <igli> it's like anti-design. <mirabilos> that too… may I quote you on that? <igli> sure, tho i doubt anyone will listen ;)

[McDutchie]

Given that ksh has static scoping, accessing the global scope is the only thing that is sensible or even feasible for typeset -g, since a function cannot access the scope of a function that calls it. So I don't see much room for rethinking it.

Even if there were, typeset -g been part of ksh 93u+m since the initial 1.0 release, so I'm not inclined to change it at this point.