From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5212 invoked from network); 9 Feb 2023 04:50:34 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 9 Feb 2023 04:50:34 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1675918234; b=d1f0wEi6EY/JoLSoJ0yDvyVZt3NNonIVXZNYhZz74czUhxWt/u7mi/XmmpPei2VZm3Q7FvGhZ0 dvn8hD3yHqHBA+TcRJaKDslI5ymSPRDKc8KgPvkcnqcDtd6d2LlsydAFywFbmFu/dZ4toYV3jO hRJDX+yzoC7jqLwczqmJFxEM9c0Ap/U8YIRfJX1wZvT1BMbDCsz0g0C67xQXNpNflCFENO3ZUj 07sUrB0sMQW8NCrJSScepODzKxmxfWm15P9/y4LyHf9tneLmnVgu8ZcA1WUbKDG3P5FoZXiwbI F8s+seWhMxexbMMH/Cx/6caWVx+AbSUgtCcvvhJqb06laA==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-ej1-f53.google.com) smtp.remote-ip=209.85.218.53; dkim=pass header.d=brasslantern-com.20210112.gappssmtp.com header.s=20210112 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1675918234; bh=WcJJqipQmADnqRfxCMW0cR+59/263joFCC8PrKoYZeQ=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=clJ+Dagv0k0/JY3FEM1u/HPa6m64ZOYBN3hlODtoKYj8nRyDZRHKH51lKzen/pH+TePbzWAlxQ qZJxzGyFgzDZM00ghfo0eF63YXEKwY0Bdpgg2hRzKtOWer1A+PStAChFyHxU4VA/SltSFUJtkV bnykUiLqJ0lX8GIwaGaMsf4JtKjezIX8vtL9NEIfUNguQZD+Z6SnrDkF9IMVATJTQo7dxf02Q8 nQjgXe31gnmHaafqpXsho/I0cpwVzW56FpWJ5ABWvBuecFAhB9iG1hVOI9vimESvsLqEmB1ylu TEe2/RgioCdJgOjB8jfxVEhv4WAVqD6MrUAzX+V8ojy/7w==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=4W/jrPijOaFT+A9No+CU9i7pZaRiibxEpxNmqx3Fo2w=; b=FHrMVJclgyGQv7wbKvEvk7BFEV FIwJzEetOrSHe5J67tM+A/YXZR+EL47jostDL6yqupznHXI9326g3oLIOLczkh2gARqSLD+OBgkk9 hikyyqt0UWBbO9/bh5uUonY6Sj3PfCzjmWIKLQ+88LY4NRY2cAnFFk9F4guereGBIGgpLjpJS3wsz CrBFUv+YbDqqN9/4BcsdlSB/fpbQ6bFo2LxXhIZdEMSvAeF0O17l79PK1MoVi4taUG5LdCJ1l1XrK BJ1L1iO+DDMXzuCrNuxvZb9dvpeRZvk/tsfDhu9sralWNvHOq/bGuQ5JmBFg1K6v73U5e8nRO0MYV WL+LbjAw==; Received: by zero.zsh.org with local id 1pPytE-000CtG-Ep; Thu, 09 Feb 2023 04:50:32 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ej1-f53.google.com) smtp.remote-ip=209.85.218.53; dkim=pass header.d=brasslantern-com.20210112.gappssmtp.com header.s=20210112 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-ej1-f53.google.com ([209.85.218.53]:43720) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1pPysb-000CXv-JD; Thu, 09 Feb 2023 04:49:54 +0000 Received: by mail-ej1-f53.google.com with SMTP id u22so2923906ejj.10 for ; Wed, 08 Feb 2023 20:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4W/jrPijOaFT+A9No+CU9i7pZaRiibxEpxNmqx3Fo2w=; b=7glX7gzRyfDaJq0Jo24AykpJE9aihLdDpf1dTbML1sXriyRlXjnaHjCyS3B+CRvL7x 3gib2z26cXoIR1/nMaQ2m9cTcKZVFWpJjDaZoeQbeo9ctzEv2H519Qp4bNhk+TxLL+Vm IOmKd+u9/zfX/Ftk1wGfDNdmQPpcCPRfInqqAiYxvMwARBv1pD8Xlxdw+I5zbhbdSF4V CxZSk7A704Jnq6E9RvPg+fEbq+xrydj7OXP6m364nLR7J53zOUWiAO7rKvX5ZvO6D65n Ws8YaVKGTYd+yemiSA0QVA7gU/HWnO/OWRfbqjkKbJds8vN9bkYQGNAqCq6j4SW8XXMs 6Xqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4W/jrPijOaFT+A9No+CU9i7pZaRiibxEpxNmqx3Fo2w=; b=0/MDu10lttxI4/QrYuffTomdX0dXlDB6q92R5/Jg5AxVVZljS48Ab0rBVPmRZ+fnFo S0bjaoKWOv3de+daxiNAs3wgiGh5eJvmk5McZHmit8231p9VjKq5U+1nZmSjMNRd0mxJ FTViMAEVXOZkeVPoI9Kfwj33yXzFoyCZ+u2vzLmVBNvEjEm8/F5/nTt9QAxJg/cH8p0c /U5JNjpMkgv1aiookr1TJPzy/zenuiv/+Bby51vSj1UJDxrj/WX9kSglfDjFBZUpk2UP Dx1rB6hHTB8BdknHw9DofR77jZevjiRsK9lDpJpYNPj9P9hDAUBF+AAh8tJUHmneT2FX bgRQ== X-Gm-Message-State: AO0yUKXXQpI2qn/eiOJe50t/JnMfXALIALwLINC9/wi9pVf5SekZAaJS ElIUsAN7jPA2Dj+34IMFMujmiKJ8VxgjebFIsp4hAQ== X-Google-Smtp-Source: AK7set99xw3rUZy9FdB+ul3FzWB8ZZ4J9/jVUSX4+NkaE2HQD8myKF9gAVTp4XqZpoW31MMwkf7HqPyHmf5m+sFbT1g= X-Received: by 2002:a17:906:4dc7:b0:877:e1ef:e49a with SMTP id f7-20020a1709064dc700b00877e1efe49amr2272853ejw.147.1675918192561; Wed, 08 Feb 2023 20:49:52 -0800 (PST) MIME-Version: 1.0 References: <67689-1675827940.088548@BxvG.D9_b.7RzI> <12608-1675903622.800470@Xj82.e3y1.svhG> In-Reply-To: <12608-1675903622.800470@Xj82.e3y1.svhG> From: Bart Schaefer Date: Wed, 8 Feb 2023 20:49:40 -0800 Message-ID: Subject: Re: [PATCH 1/3]: Add named references To: Oliver Kiddle Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" X-Seq: 51387 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: On Wed, Feb 8, 2023 at 4:47 PM Oliver Kiddle wrote: > > Bart Schaefer wrote: > > > One ksh feature which this doesn't cover is the special behaviour in ksh > > > that `typeset -n ref=$1` will use the calling function scope to resolve > > > the target. > > > > In ksh you could pass "ref" as a parameter and the nameref would provide > access to the outside variable despite the name clash. I think that will start working if I can fix the "invalid self reference" mentioned in your next message. > So [in ksh] $1 as the target of a nameref is special. [...] I don't > think we need to worry about the level of ksh93 compatibility here > because our default dynamic scoping mean a ksh script will work if > variable names don't clash. My general feeling is to be ksh compatible where I don't think ksh is stupid. > Note that Tcl's uplevel is like a precommand modifier in zsh terms so > is not limited to defining references. > > However I still prefer the other solution I mentioned with \&. I have some half-formed thoughts about other ways to accomplish this ... I don't think the \& suggestion by itself gets around the problem that the positionals are C-local to doshfunc(). > > I'm still not entirely following what problem this solves. > > It solves the problem of name clashes between a function and the calling > function. OK, so if typeset ref () { typeset -n ref=ref } works / is not a loop, then we don't need any other magic? > If two functions are developed independently, they shouldn't need > to worry about the possibility of using the same variable name for > different purposes. This is the main benefit of private in general. > An old function like _call_function (updated to use nameref but still > using local) could be used by someone writing a new function where they > pass a private variable as the first parameter. If they are treating > _call_function as a black box, how are they to know that private > variables are not valid for the passed $1. It'd be an arbitrary > limitation. I'm still not seeing that. The writer of the caller of _call_function should know that it's a general rule that another function can't access a private variable. Why would the writer pass a private name as an argument to any function, even a blackbox, if not expecting it to be referenced? The rule for a private should be that you always pass its value. Correct me if I still misunderstand, but I interpret the example above as implying that f2() { typeset -n ref=$1 # ... do stuff to $ref ... } f1() { private var f2 var } should work just because the name is passed in a positional? I would disagree with that on the grounds that you're making positionals into a special case, just a different kind of special case from ksh, that violates the intent of "private". The case I was asking about (and the only one I so far consider possibly viable) is f1() { private var typeset -n ref=var f2 ref } That is, the reference has to be declared in the scope where var is "visible", otherwise you hit the privacy wall when "typeset -n" has to up-level. Or perhaps you mean to be tagging on to your other suggestion and it would be f2 \&var which feels like syntactic sugar for my example above, with the benefit of not needing to declare an extra parameter. That's an interesting idea but I would not want this to work: f2() { typeset -n upref=\&var # ... do things to var one level up ... typeset -n uptwo=\&\&var # ... do things to var two levels up ... } I fear that puts us back to having something magic about positional parameters, e.g., that unless the "&var" string appears in one of $1, $2, ... then it's just an invalid name like any other. Back again to my half-formed thoughts, I can't really elucidate yet. > Given that you implemented references to array members, being able to > iterate over array elements with for could be nice. Perhaps something > like: for ref in 'arr[*]'; do With a hash that's just: typeset -n ref for ref in 'hash[(e)'${(k)^hash[(R)?*]}']'; do ... but since you have to "typeset -n ref" before the for-loop anyway, why not just typeset -n ref=hash for idx in ${(k)ref}; do ... $ref[$idx] ... Ordinary arrays are harder because there's no "find all matching elements" subscript flag. > On the subject references to array elements, it does seem both powerful and > dangerous that subscripts are evaluated on reference. Hm ... I implemented that because ksh93 accepted the syntax, but I never actually tried it -- in fact (Ubuntu's) ksh93 doesn't actually expand it to anything sensible and the value of the nameref ends up nonsense. > The subscript > should perhaps be evaluated with the same local level as the array > itself. That gets pretty weird, and you can already trivially bypass it with ${(P)...} for many cases. > And it could be wise to limit what can be done as part of the > subscript evaluation to avoid a CVE similar to the last one. validate_refname() is calling parse_subscript() ... would further examination of the accepted string be sufficient, or something more needed? I think the greatest danger is of creating an infinite recursion, which can't really be caught in advance.