zsh-workers
 help / color / mirror / code / Atom feed
From: Stephane Chazelas <stephane@chazelas.org>
To: Mikael Magnusson <mikachu@gmail.com>
Cc: Bart Schaefer <schaefer@brasslantern.com>,
	Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Up-scope named references, vs. ksh
Date: Tue, 5 Mar 2024 06:30:59 +0000	[thread overview]
Message-ID: <20240305063059.detbg3orz57vmvwr@chazelas.org> (raw)
In-Reply-To: <CAHYJk3TF_OmfjQmnTgayA7zmCh1gVVGtDbhkvbLvs83R84C+hg@mail.gmail.com>

2024-03-05 06:43:02 +0100, Mikael Magnusson:
[...]
> > That's actually "correct" -- from the doc:
> >
> >  When a _named reference_ is created with 'typeset -n', all uses of PNAME
> >  in assignments and expansions instead assign to or expand RNAME.  This
> >  also applies to 'unset PNAME' and to most subsequent uses of 'typeset'
> >  with the exception of 'typeset -n' and 'typeset +n'
> >
> > I admit this is a little weird when the named reference is inherited
> > from another scope.  The most recent FAQ entry that I patched actually
> > suggests using "private -n var" to prevent downward scope leakage of
> > namerefs.
> 
> Is this possible to change? I feel like if "typeset myvar" (or "local
> myvar") cannot be depended on to create a local parameter, a lot of
> code will no longer be safe that previously was (in the sense that it
> doesn't break if calling code / the shell environmnet has certain
> parameters defined). Surely we cannot expect everyone to add +n to
> every single "local" statement? If the current behavior is wanted, one
> can always use typeset -g to get it, presumably? And that would be
> more backward compatible, right?
> 
> Like say I have typeset -n foo=PS1 in my .zshrc because I don't like
> writing $PS1 manually, now any code I call which has a "local foo" is
> broken, which is not great. They have explicitly added their "local
> foo" to be able to use the name 'foo' regardless of the calling
> environment... "private -n foo" works in this case too, but I still
> hold my opinion.
[...]

I'd agree that means defining a nameref would/could break any
function that uses local variables by the same name and doesn't
sound acceptable.

See also:

$ nameref action=PS1
$ zmv -n '*' '$f.back'
zsh: segmentation fault  ./Src/zsh

Program received signal SIGSEGV, Segmentation fault.
getstrvalue (v=0x7fffffffaf70) at params.c:2343
2343            s = v->pm->gsu.s->getfn(v->pm);
(gdb) bt
#0  getstrvalue (v=0x7fffffffaf70) at params.c:2343
#1  0x000055555561369d in paramsubst (l=0x7fffffffb230, n=0x7fffffffb250, str=0x7fffffffb040, qt=0, pf_flags=4, ret_flags=0x7fffffffb154) at subst.c:2907
#2  0x000055555560dca1 in stringsubst (list=0x7fffffffb230, node=0x7fffffffb250, pf_flags=4, ret_flags=0x7fffffffb154, asssub=0) at subst.c:322
#3  0x000055555560cf87 in prefork (list=0x7fffffffb230, flags=4, ret_flags=0x7fffffffb154) at subst.c:142
#4  0x000055555560e474 in singsub (s=0x7fffffffb368) at subst.c:520
#5  0x000055555558a80e in cond_subst (strp=0x7fffffffb368, glob_ok=1) at cond.c:53
#6  0x000055555558b029 in evalcond (state=0x7fffffffc0c0, fromtest=0x0) at cond.c:198
#7  0x000055555559ba6a in execcond (state=0x7fffffffc0c0, do_exec=0) at exec.c:5185
#8  0x000055555558fe49 in execsimple (state=0x7fffffffc0c0) at exec.c:1334
#9  0x00005555555902e8 in execlist (state=0x7fffffffc0c0, dont_change_job=1, exiting=0) at exec.c:1462
#10 0x00005555555cd63d in execif (state=0x7fffffffc0c0, do_exec=0) at loop.c:561
#11 0x00005555555988aa in execcmd_exec (state=0x7fffffffc0c0, eparams=0x7fffffffbcd0, input=0, output=0, how=2, last1=2, close_if_forked=-1) at exec.c:4024
#12 0x00005555555926dc in execpline2 (state=0x7fffffffc0c0, pcode=9987, how=2, input=0, output=0, last1=0) at exec.c:2016
#13 0x0000555555591270 in execpline (state=0x7fffffffc0c0, slcode=40962, how=2, last1=0) at exec.c:1741
#14 0x00005555555904b2 in execlist (state=0x7fffffffc0c0, dont_change_job=1, exiting=0) at exec.c:1495
#15 0x000055555558fad2 in execode (p=0x555555689cd0, dont_change_job=1, exiting=0, context=0x555555630f0a "loadautofunc") at exec.c:1276
#16 0x000055555559cca0 in execautofn_basic (state=0x7fffffffc9c0, do_exec=0) at exec.c:5594
#17 0x000055555559886d in execcmd_exec (state=0x7fffffffc9c0, eparams=0x7fffffffc5d0, input=0, output=0, how=18, last1=2, close_if_forked=-1) at exec.c:4022
#18 0x00005555555926dc in execpline2 (state=0x7fffffffc9c0, pcode=3, how=18, input=0, output=0, last1=0) at exec.c:2016
#19 0x0000555555591270 in execpline (state=0x7fffffffc9c0, slcode=3074, how=18, last1=0) at exec.c:1741
#20 0x00005555555904b2 in execlist (state=0x7fffffffc9c0, dont_change_job=1, exiting=0) at exec.c:1495
#21 0x000055555558fad2 in execode (p=0x555555689b40, dont_change_job=1, exiting=0, context=0x5555556310da "shfunc") at exec.c:1276
#22 0x000055555559e88e in runshfunc (prog=0x555555689b40, wrap=0x0, name=0x7ffff7fa6168 "zmv") at exec.c:6164
#23 0x000055555559dd9e in doshfunc (shfunc=0x555555678450, doshargs=0x7ffff7fb8080, noreturnval=0) at exec.c:6010
#24 0x000055555559ca31 in execshfunc (shf=0x555555678450, args=0x7ffff7fb8080) at exec.c:5548
#25 0x0000555555598ab0 in execcmd_exec (state=0x7fffffffd6f0, eparams=0x7fffffffd300, input=0, output=0, how=18, last1=1, close_if_forked=-1) at exec.c:4075
#26 0x00005555555926dc in execpline2 (state=0x7fffffffd6f0, pcode=131, how=18, input=0, output=0, last1=1) at exec.c:2016
#27 0x0000555555591270 in execpline (state=0x7fffffffd6f0, slcode=6146, how=18, last1=1) at exec.c:1741
#28 0x00005555555904b2 in execlist (state=0x7fffffffd6f0, dont_change_job=0, exiting=1) at exec.c:1495
#29 0x000055555558fad2 in execode (p=0x7ffff7fb7b60, dont_change_job=0, exiting=1, context=0x555555633326 "cmdarg") at exec.c:1276
#30 0x000055555558f998 in execstring (s=0x7fffffffdd3b "nameref action=PS1; autoload zmv; zmv -n \"*\" \"\\$f.back\"", dont_change_job=0, exiting=1, context=0x555555633326 "cmdarg")
    at exec.c:1242
#31 0x00005555555baf25 in init_misc (cmd=0x7fffffffdd3b "nameref action=PS1; autoload zmv; zmv -n \"*\" \"\\$f.back\"", zsh_name=0x7fffffffdd34 "zsh") at init.c:1530
#32 0x00005555555bc798 in zsh_main (argc=3, argv=0x7fffffffd918) at init.c:1920
#33 0x000055555556c99d in main (argc=3, argv=0x7fffffffd918) at ./main.c:93
(gdb) p *v.pm
$1 = {node = {next = 0x0, nam = 0x555555670480 "PS1", flags = 1048576}, u = {data = 0x55555568bab0, arr = 0x55555568bab0, str = 0x55555568bab0 "", val = 93824993508016,
    valptr = 0x55555568bab0, dval = 4.6355706013588689e-310, hash = 0x55555568bab0}, gsu = {s = 0x0, i = 0x0, f = 0x0, a = 0x0, h = 0x0}, base = 0, width = 0, env = 0x0, ename = 0x0,
  old = 0x0, level = 0}




  reply	other threads:[~2024-03-05  6:31 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-06  2:21 [PATCH 1/3]: Add named references Bart Schaefer
2023-02-08  3:45 ` Oliver Kiddle
2023-02-08  4:59   ` Bart Schaefer
2023-02-08 23:16     ` Bart Schaefer
2023-02-09  0:47     ` Oliver Kiddle
2023-02-09  2:01       ` Oliver Kiddle
2023-02-09  5:45         ` Bart Schaefer
2023-02-09  4:49       ` Bart Schaefer
2023-02-09 20:49         ` Oliver Kiddle
2023-02-09 23:07           ` Bart Schaefer
2023-02-11  3:04             ` Bart Schaefer
2023-02-11  3:55               ` Bart Schaefer
2023-02-11  5:36                 ` Speaking of dangerous referents Bart Schaefer
2023-02-12  8:00                   ` Oliver Kiddle
2023-02-12  8:34                     ` Bart Schaefer
2023-02-11  7:02               ` [PATCH 1/3]: Add named references Oliver Kiddle
2023-02-11  7:45                 ` Bart Schaefer
2023-02-11 23:43                   ` Bart Schaefer
2023-02-11 23:45                     ` Bart Schaefer
2023-02-12  7:38                     ` Oliver Kiddle
2024-02-11  7:00                   ` Stephane Chazelas
2024-02-11 16:14                     ` Bart Schaefer
2024-02-11 16:42                       ` Bart Schaefer
2024-02-18  3:26                       ` Up-scope named references, vs. ksh Bart Schaefer
2024-02-20 21:05                         ` Stephane Chazelas
2024-02-20 22:30                           ` Bart Schaefer
2024-02-21 20:12                             ` Stephane Chazelas
2024-02-29  5:16                               ` Bart Schaefer
2024-03-01 18:22                                 ` Stephane Chazelas
2024-03-01 20:34                                   ` Bart Schaefer
2024-03-02  7:29                                     ` Bart Schaefer
2024-03-02 23:55                                       ` [PATCH] "typeset -nu" (was Re: Up-scope named references, vs. ksh) Bart Schaefer
2024-03-01 23:28                                   ` Up-scope named references, vs. ksh Bart Schaefer
2024-03-03 13:44                                     ` Stephane Chazelas
2024-03-03 19:04                                       ` Bart Schaefer
2024-03-03 20:27                                         ` Stephane Chazelas
2024-03-03 22:58                                           ` Bart Schaefer
2024-03-04 19:59                                             ` Stephane Chazelas
2024-03-05  1:05                                             ` Oliver Kiddle
2024-03-05  2:53                                               ` Bart Schaefer
2024-03-05  5:43                                                 ` Mikael Magnusson
2024-03-05  6:30                                                   ` Stephane Chazelas [this message]
2024-03-06  5:04                                                     ` [PATCH] local vs. nameref scoping (was Re: Up-scope named references, vs. ksh) Bart Schaefer
2023-02-12  9:02             ` [PATCH 1/3]: Add named references Oliver Kiddle
2023-02-12 18:59               ` Bart Schaefer
2023-02-12 19:45                 ` PM_* flags in zsh.h (was Re: [PATCH 1/3]: Add named references) Bart Schaefer
2023-02-12 21:01                   ` Oliver Kiddle
2023-02-12 22:54                 ` [PATCH 1/3]: Add named references Oliver Kiddle

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=20240305063059.detbg3orz57vmvwr@chazelas.org \
    --to=stephane@chazelas.org \
    --cc=mikachu@gmail.com \
    --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).