Zsh Mailing List Archive
Messages sorted by:
Re: More rabbit-holes with unset variables
- X-seq: zsh-workers 47674
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Felipe Contreras <felipe.contreras@xxxxxxxxx>
- Subject: Re: More rabbit-holes with unset variables
- Date: Fri, 27 Nov 2020 12:54:41 -0800
- Archived-at: <https://zsh.org/workers/47674>
- Archived-at: <http://www.zsh.org/sympa/arcsearch_id/zsh-workers/2020-11/CAH%2Bw%3D7arBoRxmFRH7wL_Sh-0tRe1Xyo_GKze%2BjkSdvYep7NMWg%40mail.gmail.com>
- Authentication-results: zsh.org; iprev=pass (mail-oi1-f174.google.com) smtp.remote-ip=184.108.40.206; dkim=pass header.d=brasslantern-com.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- 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=QQvnTftsrEnmSnlSTOrksdSPFl8tXs3FTcp8zHljvVM=; b=ttJ9USoSNlvargI8I3wUm/QxQJffOnRkAXWFh5bmmxb7+/jqtgaTcWWsyuAF0yvkTS 9TCQWJA//qqzDFhEVhyPq8RKQj8YLTj/Wk+5ZmPIRRBOUj3RVae3/G0ZH5ftNbTsQKv5 eODbW2s5U9+wCqumj29QSPepgymnHq4kksn4Y1QyyKBSj5VGgWzaTmgKcjtFVkCB/oS+ z7Ke1Ak1yfkhE4ccGmIuLa20EKXQiyDiIY0Tq0MfyUN4gApLHDsCI9I+D0p1qEfQf0Ur RJbW4c4AiZLRPIabyCNoIzU0IDK0CzlgGWtD7cHs4TmlQWxoMP4MNRzre3gbGZITOL6y Cuzg==
- In-reply-to: <CAMP44s2ZJg75KEh+vL+EUOgJUF+oB6TLn5-1h55ktcKR67ZeJg@mail.gmail.com>
- 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> <CAH+w=7bs9E7whJLugMLOXG05R-2S8Hjt+OOKK_KN+SMxv-Vvaw@mail.gmail.com> <CAMP44s2Ge-pOn1-gEXkq=oJX7ohL-b_20s9mJZAo1LB=ow+Duw@mail.gmail.com> <CAH+w=7bHCrpwbkZBOgwjwF7M9uo+1_ZEa53hxSwE2fuuBuQfyw@mail.gmail.com> <CAMP44s0WSt_J7TjyPEKvH9TxzWBvTVFTB-pK26G+9SacYeQrAw@mail.gmail.com> <CAH+w=7YtBvrpuXUM=MuHVRuBjf8uiRozKLJsHvYXJr9Cx=J-rQ@mail.gmail.com> <CAMP44s3s0dXtirZhi5e_Tir+3KKn2Kw4hseEj0uH12a7HB5Y=Q@mail.gmail.com> <CAH+w=7ZVthOMB=jJ+KkU1WipL2mbCgD69HfUtxGnu6Mbx1rOog@mail.gmail.com> <CAMP44s2ZJg75KEh+vL+EUOgJUF+oB6TLn5-1h55ktcKR67ZeJg@mail.gmail.com>
- Sender: zsh-workers-request@xxxxxxx
On Thu, Nov 26, 2020 at 5:30 PM Felipe Contreras
> What zsh refers to as "scalar" internally is a string:
> char *str; /* value if declared string (PM_SCALAR) */
> From Src/zsh.h (struct param).
This is exactly the discussion I was trying to avoid when I said "in
the abstract that doesn't matter".
You can't just pull one field out of a union inside a struct and
ignore the struct itself and the API for field access that goes with
> So if you didn't mean string, what did you mean?
I meant a struct param, containing the least specific thing so
represented, as interpreted through all the layers of code that
implement a dereference of its value when you write $var or any of its
variations. Again this doesn't actually matter, which is why I didn't
spell it out.
> And what did you mean by 'so a the only useful "declared but not set"
> variable is a simple scalar'?
As the very first message in this thread demonstrated, in both bash
and ksh (call this "example one", and to be pedantic assume that X is
not inheriting its name or value from somewhere):
typeset -i X
However (call this "example two"):
typeset -i X
The language you quoted from the posix proposal says "otherwise, the
variable is initially unset". Given that proposed language, example
one is incorrect, because an "unset" variable should not retain its
(in this example) integer properties when assigned a string.
> What simple scalar other than a string is useful "declared but not set"?
Under this interpretation, there isn't any. That's what I said. In
fact the last paragraph of the very first message in this thread:
"Therefore, this isn't as simple as having zsh create an unset
variable when typeset is given no assignment, because subsequent
assignment has to preserve the type of the variable, which normally
does not apply after unset."
Messages sorted by: