Re: "typeset -p" and no_GLOBAL_EXPORT, other misc.

[Stephane Chazelas <stephane@xxxxxxxxxxxx>]

2024-03-12 13:31:42 -0700, Bart Schaefer:
> On Tue, Mar 12, 2024 at 1:06 PM Stephane Chazelas <stephane@xxxxxxxxxxxx> wrote:
> >
> > 2024-03-12 11:32:41 -0700, Bart Schaefer:
> > >
> > > Looks like "integer" et al. in bash actually search for the parameter
> > > using the type [...]
> > >
> > > Does it always use outermost scope or does it just use the "nearest"
> > > integer (in this example) that it finds?
> >
> > Sorry, you're missing my point. bash doesn't have an "integer"
> > builtin.
> 
> Fine, but my point was that the type and name are both used to search
> for the parameter.  If you instead wrote:
> 
> $ f() { typeset -i i; integer i=2+2; echo "$i"; }
> 
> Would that still find the global $i instead of "the $i in f"?

My point was that the "typeset -gi i=2+2" that my integer
function does affects the variable at the outer-most scope in
bash, so typeset -g is not non-local-typeset there, but more
like typeset-at-the-outermost-scope.

Makes sense in that the "g" is meant for "global" and that
"outermost scope" for a shell with dynamic scoping is likely the
closest you can get to a "global" scope but in practice it's not
useful because in a shell with dynamic scoping there's generally
no good reason to want to single-out the outer-most scope as
more special than any other scope in the call stack while there
are often good reasons for "typeset" to just "set the type"
of existing variable without instantiating a new variable in the
current scope.

Which is why I'm saying that bash's behaviour is undesirable and
that we don't want to go there, and that zsh should carry on as
it currently does in that regard (similar to what mksh and yash
do, two other shells with dynamic scoping).

> > > Aside:  Shouldn't IGNORE_CLOSE_BRACES be set in ksh
> > > emulation?  It currently is not.
> >
> > I'd say
> >
> > $ zsh --emulate ksh -c 'echo go}' zsh:1: parse error near
> > `}' $ zsh --emulate ksh -o ignoreclosebraces  -c 'echo go}'
> > go }
> 
> Also beside the point, which is that the first of these three is wrong:
>
> % zsh --emulate ksh -c '{ echo go }'
> go
> % zsh --emulate ksh -o ignoreclosebraces -c '{ echo go }'
> zsh:1: parse error near `}'
> zsh --emulate ksh -o ignoreclosebraces -c '{ echo go; }'
> go

What I'm saying is that while ignoreclosebraces helps, it's not
*enough* to give you ksh compatibility.

AFAICT, to get ksh compatibility, } must be treated literally
unless part of brace expansion {fd}> redirs, ${...} expansions.

-- 
Stephane