From: Bart Schaefer <schaefer@brasslantern.com>
To: Peter Stephenson <p.w.stephenson@ntlworld.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCH] Named reference typos & misc.
Date: Tue, 14 Feb 2023 12:00:54 -0800 [thread overview]
Message-ID: <CAH+w=7aRann+SXDjNwQP3dh=_-e9etrhms5cL-MQp-03KWtp1Q@mail.gmail.com> (raw)
In-Reply-To: <1911575874.92635.1676392609186@mail.virginmedia.com>
On Tue, Feb 14, 2023 at 8:37 AM Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
>
> On 14/02/2023 16:14 Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > I get a passed test with or without the "unsetopt typeset_to_unset".
> >
> > Is there some way this could be platform-dependent?
>
> Here's a minimal case:
I can reproduce the (lack of) error message with your minimal case.
Gets odder. I added
set -o
to the test (otherwise exactly as pushed) and the output includes
+typesetsilent off
+typesettounset off
+nounset off
I've no idea how/where it gets turned off, though.
If I strip down K01 to just that single test, the error message
doesn't happen (test fails).
If I make setopt into a wrapper function in the %prep section, test
fails, but I don't see any change to that option emerging from the
wrapper function (directs to /dev/tty).
If I remove the setopt from %prep entirely, the other tests that rely
on it, fail, so it IS set.
By binary search, I found the option state changes for me after this test:
typeset ptr2=var2
typeset var2=GLOBAL
() {
typeset -n ptr1=ptr2
typeset ptr2=var1
typeset var1=VAR1
typeset var2=VAR2
print -r -- ${(P)ptr1}
}
0:
>VAR2
For which I forgot to write a description, but it's supposed to check
order-of-evaluation for namerefs and (P).
Running that test standalone does not cause the option to change:
Src/zsh -f =(<<\EOF
setopt localloops
() {
setopt typeset_to_unset
typeset ptr2=var2
typeset var2=GLOBAL
() {
typeset -n ptr1=ptr2
typeset ptr2=var1
typeset var1=VAR1
typeset var2=VAR2
print -r -- ${(P)ptr1}
}
print $options[typesettounset]
}
EOF
)
VAR2
on
I have no idea how to debug this. Thoughts? I would suspect it's
more related to the test harness than to the named reference changes.
I tried removing the EXECOPT frobbing around subscript evaluation,
that made no difference (except for the test specifically about that).
Unrelated:
> I kept the loop in the function to avoid a (correct) additional warning
> message setting the global variable ref in the loop. I don't know if
> setting ref in a for loop should actually elide that message, which
> is a completely separate issue.
You mean an assignment within the loop, while "ref" already points out
of it? I would think that'd be expected to trigger warn_create_global
instead,
next prev parent reply other threads:[~2023-02-14 20:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-14 2:08 Bart Schaefer
2023-02-14 14:46 ` Peter Stephenson
2023-02-14 16:14 ` Bart Schaefer
2023-02-14 16:36 ` Peter Stephenson
2023-02-14 20:00 ` Bart Schaefer [this message]
2023-02-15 1:39 ` Bart Schaefer
2023-02-16 15:29 ` zmodload (-u?) changing options (was Re: [PATCH] Named reference typos & misc.) Bart Schaefer
2023-02-16 15:52 ` Peter Stephenson
2023-02-16 18:17 ` Bart Schaefer
2023-02-16 19:28 ` Bart Schaefer
2023-02-16 23:10 ` Bart Schaefer
2023-02-21 11:47 ` Peter Stephenson
2023-02-21 12:11 ` Peter Stephenson
2023-02-21 15:57 ` Bart Schaefer
2023-02-15 10:12 ` [PATCH] Named reference typos & misc Peter Stephenson
2023-02-15 10:36 ` Peter Stephenson
2023-02-15 14:58 ` 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='CAH+w=7aRann+SXDjNwQP3dh=_-e9etrhms5cL-MQp-03KWtp1Q@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=p.w.stephenson@ntlworld.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).