Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: More rabbit-holes with unset variables
- X-seq: zsh-workers 47660
- From: Felipe Contreras <felipe.contreras@xxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: More rabbit-holes with unset variables
- Date: Thu, 26 Nov 2020 19:51:07 -0600
- Archived-at: <https://zsh.org/workers/47660>
- Archived-at: <http://www.zsh.org/sympa/arcsearch_id/zsh-workers/2020-11/CAMP44s3NYQA3OSvdEBQ5bNG2O2%2Bw0U3USUvBP7Mi-3urhuKYzg%40mail.gmail.com>
- 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
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- 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==
- In-reply-to: <CAH+w=7Yv1FO4eTSZfTADPJMz++COsFQJ3UKzGbWF4JdCtcV83g@mail.gmail.com>
- List-archive: <http://www.zsh.org/sympa/arc/zsh-workers>
- List-help: <mailto:sympa@zsh.org?subject=help>
- List-id: <zsh-workers.zsh.org>
- List-owner: <mailto:zsh-workers-request@zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-subscribe: <mailto:sympa@zsh.org?subject=subscribe%20zsh-workers>
- List-unsubscribe: <mailto:sympa@zsh.org?subject=unsubscribe%20zsh-workers>
- References: <CAH+w=7Zag5MG5D=cRS2UMSsqJ0t=iw5MH9j8=HBO1Q77nbs03w@mail.gmail.com> <20201125131921.vay7h3xk5qn4odgg@chazelas.org> <CAMP44s0-ki=TBzTwnqx10FcTLX4mbphwN88UCx0+h97JTecBWA@mail.gmail.com> <20201126061029.in5tpnrg5bplam5k@chazelas.org> <CAMP44s1XgxdDAAL+7nL3_GK=dZUasPmSWZaKqWg0T-v5iq1eYg@mail.gmail.com> <86243-1606389706.499549@-gQx.nNYG.4Z3k> <CAH+w=7bxavq4DMJtTmSAGTOSoXKsFaXPVyUAGqN1cZLF=+57JQ@mail.gmail.com> <CAMP44s3h2q42=y_fbts5mbgb8oYXYVxKrXQUS35k205X1i15OQ@mail.gmail.com> <CAH+w=7ZgzpTtjcnQ4mmZVAZzi=TE_m1dW0AZQm5oLhMDyG8pZg@mail.gmail.com> <CAMP44s1pMOrXAYR+VO-acM0dc0KN7SUkcdGEF7RfanfDN8aHfg@mail.gmail.com> <CAH+w=7Yv1FO4eTSZfTADPJMz++COsFQJ3UKzGbWF4JdCtcV83g@mail.gmail.com>
- Sender: zsh-workers-request@xxxxxxx
On Thu, Nov 26, 2020 at 6:23 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Thu, Nov 26, 2020 at 3:53 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> 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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author