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.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,RDNS_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.4 Received: from authenticated user by zero.zsh.org with local id 1kijw2-000MF2-Ie; Fri, 27 Nov 2020 20:01:38 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ot1-f42.google.com) smtp.remote-ip=209.85.210.42; dkim=pass header.d=brasslantern-com.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none Received: from mail-ot1-f42.google.com ([209.85.210.42]:33750) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1kijvh-000M0K-4a; Fri, 27 Nov 2020 20:01:18 +0000 Received: by mail-ot1-f42.google.com with SMTP id n12so5666509otk.0 for ; Fri, 27 Nov 2020 12:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MramQ0TWBPF8K7WygYHyYueaTQY+3MvMxwP4dZyE3Tc=; b=Yc3efsZRJSbW2DEN2un0mUCYjZMBlBWyPHCl/32o4VQlSq3F9EINulXcXY48d7Cxl+ X2HBAs6aQ7+S/fF3f9HIChwCA/U//DPD5rKIlaBr6VQrXae3QaF5++z/omuAmRhRbkt+ pMqE4Q+SxXv7OdG168bRYTi1cs652t6dRj7qhU1crDBpmP8W7/EDzT+6ta9JXVBjQfJK FdbbHMtofCsoYfSf3CMODwZSVk7kKxYNGFVXAfXXqt0Kgc0wwIbuD9tfkCYmuomxzXQB NX0Bg2N+S6GfnXiudP+6/mvZECxPP7zZU3SR0EIwWlgBN/WlSKK/iAv8kiFq3YS1MVo5 lCyw== 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=MramQ0TWBPF8K7WygYHyYueaTQY+3MvMxwP4dZyE3Tc=; b=I8IMshl+CRpHEMNkV3gv0Br8i5E/pSi9X8LOrE5b6gRb1so6AC2JQtGIk/uD9MvwQk 18Ol2UJLZRgrAF4WgQ3Mu1Y0pucHfgqBKH0p193Ae2ywu8arUy2LbR/Q4qG4kklQdTAU uyZ+XcNwYCv+zjBd2QiAY41T4UCJcUgtEACPFWLIYy+sRK7USPtwUC02AqQmYRuhIzED hjG7Y+bieFzFwx5FPzEeUP+lhaECYjFMF2ZRadHp45p06P00TS5o1JiO49YUxOpe11Fp HdQ9zTdKSLD8ZvENxofdIn9d751H0W5AqlHEbyj6MaOGk83nWf6pkZruIr+I37YKCHd3 4s9g== X-Gm-Message-State: AOAM533ca9IbQosdR9yjvKUsZn4DXPh4+tksVygwoXMS/1faqhxpHUGD FyusPyMQ398av5b/yDUm9+233dQj0LRonLB8Af8E0A== X-Google-Smtp-Source: ABdhPJyNOCLToL8zf1SM6kyJesDpaENVfWta4gfAVfFBlr9v3rx60MgYSfVk+EY3zNJh7EqGNUgv2nvPaW3umvO0cgA= X-Received: by 2002:a05:6830:1552:: with SMTP id l18mr7715715otp.229.1606507275173; Fri, 27 Nov 2020 12:01:15 -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: Bart Schaefer Date: Fri, 27 Nov 2020 12:01:03 -0800 Message-ID: Subject: Re: More rabbit-holes with unset variables To: Felipe Contreras Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" X-Seq: 47669 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: My use of "rabbit holes" has been even more prophetic than I expected. (Ironically, spellcheck wants to correct that to "pathetic".) 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 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. > 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. > 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. This is entirely separate from whether there is a 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. Is there an inconsistency from the viewpoint of an omniscient observer? Yes. As a practical matter, can either a script written entirely in zsh, or an external program invoked from zsh, independently discern this inconsistency? No. I'm done with responses about export behavior on this thread except when directly related to the treatment of default values.