From: Stephane Chazelas <stephane@chazelas.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: "typeset -p" and no_GLOBAL_EXPORT, other misc.
Date: Tue, 12 Mar 2024 20:06:46 +0000 [thread overview]
Message-ID: <20240312200646.znbo4dw3rocza335@chazelas.org> (raw)
In-Reply-To: <CAH+w=7Z40c_8k1FHra0K9iQvih=4LZmS-pkx06o_CiDf0wTJJQ@mail.gmail.com>
2024-03-12 11:32:41 -0700, Bart Schaefer:
[...]
> > bash-5.3$ f() { local i; integer i=2+2; echo "$i"; }
> > bash-5.3$ f
> >
> > bash-5.3$ echo $i
> > 4
> >
> > That "integer" changed the type of the global (outer-most) i
> > variable instead of that of its caller.
>
> Looks like "integer" et al. in bash actually search for the parameter
> using the type (which corresponds to what zsh attempts to do when
> using -p), rather searching for the parameter name and then altering
> the type (which zsh without my patch sometimes does by accident).
>
> 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. I was defining a:
integer() { typeset -gi "$@"; }
*function* to demonstrate the undesired behaviour of bash's
typeset -g.
[...]
> > ksh93 does static scoping
>
> As someone else pointed out elsewhere, this depends on whether you do
> foo() { ...; }
> or
> function foo { ...; }
> but really, I don't care, as we don't emulate this bit anyway.
Yes, Bourne-style functions in ksh93 do no scoping at all
whether static or dynamic.
If you use "typeset" in a Bourne-style function in ksh93, that
will affect or instantiate the variable in the inner-most
Korn-style function in the call stack, or the global scope if
there are only Bourne-style functions in the call stack.
Calling a Bourne-style function in ksh in effect is like dumping
the body of that function on the spot when it comes to scoping.
That has its uses to work around the strictness of the
Korn-style statically scoped functions. You could do for
instance:
int() typeset -i "$@"
there.
> 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 }
Are both wrong for ksh compatibility.
$ zsh --emulate sh -c 'echo go}'
go}
~$ zsh --emulate sh -c 'set -o' | grep brace
braceccl off
noignorebraces off
ignoreclosebraces off
~$ zsh --emulate ksh -c 'set -o' | grep brace
braceccl off
ignorebraces off
ignoreclosebraces off
$ zsh --emulate ksh -o ignorebraces -c 'echo go}'
go}
But that disables braceexpansion (which is or is not enabled by
default on ksh depending on the implementation, version, how it
was compiled and the setting of the braceexpand (and posix in
ksh93u+m) options).
Newer versions of the POSIX spec allow (but don't require nor
specify) brace expansion, so it doesn't need to be disabled
in sh emulation any longer (but doesn't need to be enabled
either). Same for {fd}> ...
See https://www.austingroupbugs.net/view.php?id=1193
--
Stephane
next prev parent reply other threads:[~2024-03-12 20:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-12 4:13 Bart Schaefer
2024-03-12 8:49 ` Stephane Chazelas
2024-03-12 18:32 ` Bart Schaefer
2024-03-12 20:06 ` Stephane Chazelas [this message]
2024-03-12 20:31 ` Bart Schaefer
2024-03-12 20:48 ` Stephane Chazelas
2024-03-12 21:02 ` Bart Schaefer
2024-03-12 20:26 ` Stephane Chazelas
2024-03-12 20:38 ` Bart Schaefer
2024-03-12 20:58 ` Stephane Chazelas
2024-03-12 21:03 ` Bart Schaefer
2024-03-13 0:52 ` {PATCH] (for real this time) " Bart Schaefer
2024-03-14 2:11 ` [PATCH] More "typeset -p" and GLOBAL_EXPORT Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240312200646.znbo4dw3rocza335@chazelas.org \
--to=stephane@chazelas.org \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).