Zsh Mailing List Archive
Messages sorted by:
Re: More rabbit-holes with unset variables
- X-seq: zsh-workers 47633
- From: Felipe Contreras <felipe.contreras@xxxxxxxxx>
- To: Felipe Contreras <felipe.contreras@xxxxxxxxx>, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>, Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: Re: More rabbit-holes with unset variables
- Date: Thu, 26 Nov 2020 01:20:48 -0600
- Archived-at: <https://zsh.org/workers/47633>
- Archived-at: <http://www.zsh.org/sympa/arcsearch_id/zsh-workers/2020-11/CAMP44s1XgxdDAAL%2B7nL3_GK%3DdZUasPmSWZaKqWg0T-v5iq1eYg%40mail.gmail.com>
- Authentication-results: zsh.org; iprev=pass (mail-wm1-f48.google.com) smtp.remote-ip=184.108.40.206; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none
- 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; bh=AwlVwGat8bOVWSo+S7kY0YssX86bBaqjNmpOHj752nQ=; b=QGo3iqUakCje1sw8d5L0zwPhG5QaAn5PQwM4fmqDEqoJkjfBSQsvgBWqcZLSdigHea zhxmTlLeUzbkZzZyQELIzDksOTjRAHGIDkXmSqIyKNpTL4M1otVdZPSEoJfEJWNb69AQ yMscDj/YS088/VwLl+BXkBkPMb+h7vxSPEUx7auJDIFPOlyzKR4qvP10OQpuY3Y9i0xW x/n5o9hDdgdiYSDpwAKDFHVru/G9lx5g7Pv6DC0EtQTItU/nMb84AKl+WliCrBu9W8Tb 1pcDussNXCmBRRXLPZUvWYSqANohPd1/6PFkWrWKQrDVVIzqzwqnR5zJPIPM98aKX51G sbzQ==
- In-reply-to: <firstname.lastname@example.org>
- List-archive: <http://www.zsh.org/sympa/arc/zsh-workers>
- List-help: <mailto:email@example.com?subject=help>
- List-id: <zsh-workers.zsh.org>
- List-owner: <mailto:firstname.lastname@example.org>
- List-post: <mailto:email@example.com>
- List-subscribe: <mailto:firstname.lastname@example.org?subject=subscribe%20zsh-workers>
- List-unsubscribe: <mailto:email@example.com?subject=unsubscribe%20zsh-workers>
- References: <CAH+w=7Zag5MG5D=cRS2UMSsqJ0t=iw5MH9j8=HBO1Q77nbs03w@mail.gmail.com> <firstname.lastname@example.org> <CAMP44s0-ki=TBzTwnqx10FcTLX4mbphwN88UCx0+h97JTecBWA@mail.gmail.com> <email@example.com>
- Sender: zsh-workers-request@xxxxxxx
On Thu, Nov 26, 2020 at 12:10 AM Stephane Chazelas
> As to unset vs initial value, both have merits. While I'd tend
> to prefer "initially unset", it makes sense that "local -i i;
> echo "$i"" outputs an integer. Or that "local -Z2 v; echo $#v"
> outputs 2.
Yes, when you are specifying a type, it's obvious what default value
you would want, and at least to me it makes sense that "typeset -a
arr" initializes $arr with an empty array. But that's not what was
The discussion is about what "typeset var" (with no type) should do.
> In any case, I don't think zsh can change its default behaviour
> as it would break backward compatibility.
That's what major versions are for (maybe zsh 6.0?), and backwards
compatibility has been broken before.
Anyway, in the current state of the discussion, the idea is to add the
unset behavior to "setopt ksh_typeset", so no backwards compatibility
would be broken.
> It could try and emulate ksh in ksh emulation, but which ksh?
> ksh88, ksh93 and mksh behave radically differently in that
> regard. Also few people use ksh these days, so I'm not sure it's
> worth the effort. While the ksh emulation mode can help with
> bash compatibility, bash's behaviour in this instent is also
> very different.
When no type is specified, both ksh and bash do the same thing: no
initial value is assigned.
I don't want to say "unset", since as you explained; that can entail a
lot of different behaviors depending on the shell. But rather: nil
Can we agree that it makes sense that "typeset var" (with no type)
assigns $var the nil value (in other words: no value) (or at the very
least no value in the case that no global $var has been previously
Messages sorted by: