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 1kiSvC-000Imf-VE; Fri, 27 Nov 2020 01:51:39 +0000 Authentication-Results: zsh.org; iprev=pass (mail-wr1-f45.google.com) smtp.remote-ip=209.85.221.45; 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-f45.google.com ([209.85.221.45]:43008) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1kiSus-000IXx-Ub; Fri, 27 Nov 2020 01:51:19 +0000 Received: by mail-wr1-f45.google.com with SMTP id s8so3986807wrw.10 for ; Thu, 26 Nov 2020 17:51:18 -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=66Efbaw+nOiHs0Tg5wZBTC7CgzpRrB3HrTsphXpEa78=; b=LEq94W5wpPAYrzeLnocDV2A1/v1IOC3EyOWKCuu15YmzTqUaiU3mZzcGUlw3oOfKoM RCieWGNeXKDOdc5VHHjq7/4AyoeorkPm7S1kylGg+OXSEvVzK1+meTETrCq/TCvTzER7 19+FDEPQkKFYDwHWHFcl4v7eTxqml/107exq/wDxyKR3LDt+NC4WExYLzbyAF/q5C+RG hJnnkRnC3Og4SK5grfDOPslyV9wPcv5SgrSy08FAFVSh+CdELK8IGyaft7FGQviYnOQu +4GRN71CnbsY4T1diM2+bA6+GMzTyphI/D54nwQL5mbnjkddd6REpVXg6g4bqBo0/C2I Taiw== 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=66Efbaw+nOiHs0Tg5wZBTC7CgzpRrB3HrTsphXpEa78=; b=QFD7T81rHM66fMSXDG6S+MVYKLvJiFJruD8MLJ9b4REbXnmvV+qp4vjuWoygUX9VDj JrbBkH5BJwNESMa7PzKlP7Y9Pb5hGnqWIXAnRkv+G0mrXScCkVwwXZ4colyuZ/qj/P1g Pfqi5wFZqV9YyrLR8Icjy4SaohQOmVBbYOs5+FY3co6MGN+ouDKOZWhsQL5F6sy8fwh0 g/cJwIQsPPz6ikjzpdgwkEvYA5mWzsH7CrNrSdKo9EvskE3wF9QWnL36Kl0OllQRE992 +CZakv2bWpXo9+MBQ+0gj/uT2aow9DcpBiPWirmKAdOSt6d5K1pLJFpIOSf2DfGeY27N dEJA== X-Gm-Message-State: AOAM531d1+dldHgcrs7vMFz0tYjjcE4rv1B026eKitVp4UJpA6SVFlOX n0pyNcxWsCM6iIlGyB3lqySi2quJaZGOlH/IgDI= X-Google-Smtp-Source: ABdhPJwVaGjPzuIulnWXNzfukNhFNhnjLW/1ll2fqyuDjXXjtLnB6+3bqsE5SvjbiVGTWwQ0DROYBYxyIYI8iESPYa0= X-Received: by 2002:a5d:474f:: with SMTP id o15mr7354504wrs.100.1606441878618; Thu, 26 Nov 2020 17:51:18 -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: Thu, 26 Nov 2020 19:51:07 -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: 47660 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 Thu, Nov 26, 2020 at 6:23 PM Bart Schaefer wrote: > > On Thu, Nov 26, 2020 at 3:53 PM Felipe Contreras > wrote: > > > > > There's no way to "see" the export namespace without forking an > > > external process, so only the internal value matters. > > > > No. The exported value exists whether you decide to look at it or not. > > 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? The example brought by Oliver was this: export FOO echo ${FOO-replacement} How do you know FOO doesn't have a value beforehand? That's precisely the reason the "-replacement" part is there: FOO may or may not have a value. You used precisely this argument when I brought up this example: func () { [[ -n "$1" ]] && var=$1 dosomething ${var-other} } You said: "It's not possible to write deterministic code." It is exactly the same thing here. If we have this example: [[ -n "${1+set}" ]] && FOO=$1 func () { export FOO sh -c 'echo "external: \"${FOO-nil}\""' echo "internal: \"${FOO-nil}\"" } func % sh example.sh bar external: "bar" internal: "bar" All shells I have return the same. But when I do the same without argument: % sh example.sh external: "nil" internal: "nil" In all shells, except: % zsh example.sh external: "nil" internal: "" The inconsistency between the internal and external value *only* happens in zsh, and it most definitely exists. > > > > typeset -x FOO > > > > > > > > Is different than this: > > > > > > > > typeset -x FOO="" > > > > If this is not inconsistent, then nothing is. > > Now I'm confused. All along you've been arguing that { typeset FOO } > SHOULD differ from { typeset FOO="" }. Why does adding -x invert your > argument? It doesn't. To be consistent, either these two are the same: typeset -x FOO typeset -x FOO="" Or these two are different: typeset FOO typeset FOO="" As long as in zsh none of these are changed, zsh is objectively inconsistent. It is *two* inconsistencies. What I think is obvious should be changed is the latter, so that: typeset -x FOO typeset FOO In both cases FOO is "unset", both locally and externally. And. typeset -x FOO="" typeset FOO="" In both cases FOO would have an empty string both locally and externally. I don't see how this *second* inconsistency isn't obvious. Cheers. -- Felipe Contreras