On Tue, Mar 12, 2024 at 1:38 PM Bart Schaefer wrote: > > On Tue, Mar 12, 2024 at 1:26 PM Stephane Chazelas wrote: > > > > $ zsh -c 'a() { export a; a=3; typeset -p a; }; b() { local a=2; a; typeset -p a; }; a=1; b; typeset -p a' > > export -x a=3 > > typeset -x a=3 > > typeset a=1 > > > > That export -x seems bogus BTW as export doesn't accept the -x > > option. > > Indeed, that's a bug in the printparamnode() routine. That's not the only bug. As demonstrated by B02typeset.ztst in the test no array/hash in POSIX export/readonly -p with a declaration in a function of local -rx zsh_exported_readonly_scalar=1 the output of "export -p" is typeset -rx zsh_exported_readonly_scalar=1 However, "local" is supposed to supersede the GLOBAL_EXPORT option, so that should have output one of typeset +g -rx zsh_exported_readonly_scalar=1 or local -rx zsh_exported_readonly_scalar=1 The attached patch changes this (using "local"). The POSIX mode output -- export zsh_exported_readonly_scalar=1 -- is explained by a comment: * The zsh variants of export -p/readonly -p also report other * flags to indicate other attributes or scope. The POSIX variants * don't. There is also an AFAICT insurmountable problem: innie() { typeset -p $1 } outie() { local -x $1; innie $1 } outie var displays export var='' That is "correct" in that var is not local to outie, but that statement cannot be evaluated to restore the state of $var anywhere other than from functions called by innie. Conversely: innie() { print ${(tP)1} } outie var displays scalar-local-export Which is also "correct" but fibs about $var being local to innie. Finally we have innie() { typeset +m $1 } outie var which agrees with the (t) flag by reporting local exported var And innie() { typeset -m $1 } outie var yielding var='' No mention of export at all. These are all long-standing behaviors and haven't caused anyone a problem yet that I know of, so I'm not suggesting anything change, just pointing out that this patch doesn't address them.