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=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,RDNS_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.4 Received: from authenticated user by zero.zsh.org with local id 1kilck-0000mZ-6A; Fri, 27 Nov 2020 21:49:50 +0000 Authentication-Results: zsh.org; iprev=pass (mail-wr1-f47.google.com) smtp.remote-ip=209.85.221.47; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-wr1-f47.google.com ([209.85.221.47]:36212) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1kilcM-0000XQ-OA; Fri, 27 Nov 2020 21:49:28 +0000 Received: by mail-wr1-f47.google.com with SMTP id z7so6952118wrn.3 for ; Fri, 27 Nov 2020 13:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VxKYwcnShNdxMOCKaKoCo43XjO5IksjllruLBqSKVKg=; b=hSJ2ibvHPkGAWFUk9fs6KYH17blzzG+EjUpqBY/+3tt0hCZTdDip0PL6fnfU3Cn+nX i0MRXP6rrtdHc5cHHNZBglPUMVIji7pKFQDO2P1QU+dvD85fLInYpqIWgbEH04sk4PtZ FwyvwS6TWayCF5Hcq264aq2MFf5dZW5JLe6EhBKaOgtBMsVDA4ckUR0lNKSzwHjk/tT6 cL9jzoU51WRr1J9RxDOLAwxwAP5WLyhcQEZrMyiiOr/XK5oKyXtfdcdowqQ5QlVjh1FL girXL1lsniojRuco0urUtX+KKkpTn/TLy2swgyr0Wwx7x8m/ZiSPM+C1bnL9Y8Qb+oXv O5eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VxKYwcnShNdxMOCKaKoCo43XjO5IksjllruLBqSKVKg=; b=q7Nmt4RiDk+qKjqL0v+mz11ReOKFeKz7ChEPR+0V6aaPI7Tmwq4YYo9gGtKxzp4W5E 8bCq2oE30QNgoniZMVGNuhBcfuZQBLB9PjnPQrnp6V8mln80fFV04Ur0GuT1Q5//AD6I On/8Ytkq1ClR27xlDdQ0um8X+R30rzz3XnP4kkIN4d9DzKzhyRy6rHxvo6L5pbKHIomn IhVWI22yXGHYeSAzjPJUsE7mSLCy3FfXpalFMkB2ayphivgYs7UWhNIV4QNBoC4Jr/HE 1tF37O13sIJfLBR3ykz43UZCMTLqg3V+CuXFPfCqfVRsrwdY0X3baJucAtZDhV0lOZQW bJ1w== X-Gm-Message-State: AOAM530mFb6rWR8jW4k5E0eg3N/I4wJUOvMUIjNFsMUgtx7tkf4xGt4i 2NCO2xWsspMH06YGA7cUaEQW1TY3oR9f0ePbljEcBpBUcccWnA== X-Google-Smtp-Source: ABdhPJx6IOR+ZXlO3lcSaRL7F+QctzUivGgJVJnKTHV9zNTZIGZap3yW0AuQm3PLA96FboUm1Nb9exSsnHI1Jd+0QPI= X-Received: by 2002:adf:e788:: with SMTP id n8mr13410191wrm.84.1606513766364; Fri, 27 Nov 2020 13:49:26 -0800 (PST) MIME-Version: 1.0 References: <20201125131921.vay7h3xk5qn4odgg@chazelas.org> <20201126061029.in5tpnrg5bplam5k@chazelas.org> <86243-1606389706.499549@-gQx.nNYG.4Z3k> In-Reply-To: From: Felipe Contreras Date: Fri, 27 Nov 2020 15:49:15 -0600 Message-ID: Subject: Re: More rabbit-holes with unset variables To: Bart Schaefer Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" X-Seq: 47677 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: Archived-At: On Fri, Nov 27, 2020 at 2:01 PM Bart Schaefer wrote: > > My use of "rabbit holes" has been even more prophetic than I expected. > (Ironically, spellcheck wants to correct that to "pathetic".) There's no rabbit hole here. It's obvious that zsh's behavior is inconsistent. If trying to defend that it's not seems like an impossible endless endeavor, well, maybe there's a reason for that. > On Thu, Nov 26, 2020 at 5:51 PM Felipe Contreras > wrote: > > > > On Thu, Nov 26, 2020 at 6:23 PM Bart Schaefer wrote: > > > > > > The point is that the exported value DOES NOT exist in this example; > > > if you were to look at the C global "environ" array following "export > > > FOO", it would not have (a pointer to a string containing) "FOO" in > > > it. > > > > How do you know? > > By paying attention to context? > > We're not talking about Oliver's example at this point, we're talking > specifically about the case where "export FOOBAR" creates a global > variable that did not exist before. If it did previously exist, then > the internal and environment namespaces would be the same. The only > way for them to differ is when FOOBAR did not already exist. You should not be so assuming as to what "we" are talking about, maybe you were not talking about that, I was, and it should be clear from where we came from: Oliver: > > > > > > It appears that export VAR will not export an empty VAR even in zsh (unless you do VAR=""). So zsh's not exactly consistent. typeset [-x] is arguably just a variant of export. > > > > > > This does change how I regard zsh's behaviour. It isn't zsh taking a different but equally valid approach on an extension but an sh incompatibility. It once was a bug even if now too entrenched. Bart: > > > > > It doesn't export the empty string at the time the parameter is declared, but it does consistently set it to empty string internally: Felipe: > > > > And you don't find it inconsistent that the internal value is *different* from the exported value? Bart: > > > That's a loaded question, because to answer it requires conceding that there exists an exported value from which the internal value differs. There's no way to "see" the export namespace without forking an external process, so only the internal value matters. Felpe: > > No. The exported value exists whether you decide to look at it or not. Bart: > The point is that the exported value DOES NOT exist in this example Cleary I am talking about Oliver's example: echo ${FOO-replacement}. > > You used precisely this argument when I brought up this example: > > Not the same, because the behavior of export vs. local (typeset in > function context) is not the same; the latter always creates a new > variable, and that variable doesn't inherit from scope. Analogies don't have to be the same. > > The inconsistency between the internal and external value *only* > > happens in zsh, and it most definitely exists. > > I have never denied that. What I said was that if you never leave > zsh, you can't tell. That you can tell by forking off /bin/sh is > because of the way the internal and external namespaces are managed, > not because of the way the internal namespace works, and I'm > unsuccessfully attempting to keep this thread focused on the latter. It doesn't matter if you can tell or not; the two values exist, and they are different, and they are different *only* in zsh. > > To be consistent, either these two are the same: > > > > typeset -x FOO > > typeset -x FOO="" > > > > Or these two are different: > > > > typeset FOO > > typeset FOO="" > > In the internal namespace, and starting from a name FOO that's never > been used/does not appear in the process environment, in zsh all of > these do the same thing: > > declare FOO > local FOO > export FOO > > To use Daniel's "${verb}s a variable" from the other thread, ${verb} > is 'creates an internal parameter to represent'. The entirety of > these two discussion threads is supposed to be about when it is > appropriate for that to have a default value, and what it means for it > not to; currently it always has one. > > Specifically for "export" there are two additional requirements: > 1) If the variable already exists with a value, then variable=value is > added to the environment. > 2) If a value is later assigned to the variable, then variable=value > is added to the environment. > > Neither of those requirements is met under the stated conditions, so > nothing is added to the environment. You are just describing existing behavior. > This is entirely separate from whether there is a default. No, it isn't. This is an unsubstantiated claim. *If* you are going to assign a default value, then this is the value that should be exported. Otherwise the values will be different, and there would be an inconsistency. *Or* just don't assign any default value, and this way both the local and exported values are also the same. So clearly the inconsistency has to do with the default. > Again starting from a previously nonexistent FOO, all of these are > also the same: > > declare FOO=anything > local FOO=anything > export FOO=anything > > These explicitly do two things: First ${verb}, and then assign. So > for export, the second additional requirement is met, and > variable=value is added to the environment. Again, explaining current behavior. > Is there an inconsistency from the viewpoint of an omniscient > observer? Yes. Good. That's all I'm saying, and that's what Oliver said (zsh's not exactly consistent). Cheers. -- Felipe Contreras