From: Bart Schaefer <schaefer@brasslantern.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Roman Perepelitsa <roman.perepelitsa@gmail.com>,
Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Bug with unset variables
Date: Tue, 17 Nov 2020 12:54:35 -0800 [thread overview]
Message-ID: <CAH+w=7a3vOa2+YXpOS0eCGTr_TGNe1uhPBu+B1Xb_4OmmhJk1A@mail.gmail.com> (raw)
In-Reply-To: <CAMP44s0sU0B1fQq=BEJV+jp_jtjxpFbz6K=wqNpukLK4i31P4g@mail.gmail.com>
On Mon, Nov 16, 2020 at 11:42 AM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> Declared is not the same as defined.
True, but in the shell language traditionally the only way to declare
a variable was to define it. The exception was "export VAR" which has
so far been out of scope (ha ha) for this discussion, and later
"readonly VAR" which has limited use if VAR is not also defined.
> All languages we explored have the same notion (inside a function):
I'm just going to excerpt one of these because you claim they're all
the same ...
> Python:
>
> foo = None
> print(foo) # None
> foo = "set"
> foo = None # unset()
> print(foo) # None
>
> Shell:
>
> local foo
> echo ${foo-nil} # nil
> foo="set"
> unset foo
> echo ${foo-nil} # nil
>
> These are all functionally *exactly* the same. And that's an undeniable fact.
Except your examples are NOT the same. Your shell example introduces
what amounts to a ternary test. In shell
local foo
echo -n $foo
does not output "nil" or "undefined" or "None", it outputs NOTHING.
When you throw in ${foo-nil} you're effectively writing (pseudo code)
if the variable foo has no value
then substitute nil
else substitute the value of foo
fi
There literally is no concept of "not defined" in the shell language
outside of that implicit ternary; undefined is not a first-class
value. You cannot write "if [[ $foo == undefined ]]" or any of the
similar comparisons that can be done in most if not all of the other
languages you assert are equivalent. You can use $anydamnthing in the
shell anywhere an empty string can be used, without producing a null
dereference or similar error -- unless of course you've activated
NO_UNSET, which by the way:
nounset_error() {
setopt localoptions nounset
print $foo # error
}
nounset_ok() {
setopt localoptions nounset
typeset foo
print $foo # not error
}
So the decisions made about the behavior of typeset have ramifications
beyond your use case.
> > > The most straightforward way is not necessarily the best way.
And the perfect is often the enemy of the good. Let's stop throwing
aphorisms at each other, especially when they can't change decisions
made decades ago.
> KSH_TYPESET does something else that not even ksh does. But another
> option might make sense.
Which particular something are you thinking of?
next prev parent reply other threads:[~2020-11-17 20:55 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-11 15:57 Felipe Contreras
2020-11-11 16:13 ` Roman Perepelitsa
2020-11-11 16:56 ` Felipe Contreras
2020-11-11 17:02 ` Roman Perepelitsa
2020-11-11 18:03 ` Felipe Contreras
2020-11-11 18:16 ` Roman Perepelitsa
2020-11-11 20:42 ` Felipe Contreras
2020-11-12 0:20 ` Mikael Magnusson
2020-11-12 1:10 ` Felipe Contreras
2020-11-12 8:45 ` Roman Perepelitsa
2020-11-12 10:47 ` Peter Stephenson
2020-11-12 18:48 ` Bart Schaefer
2020-11-12 19:49 ` Felipe Contreras
2020-11-12 18:46 ` Felipe Contreras
2020-11-12 19:10 ` Roman Perepelitsa
2020-11-12 21:08 ` Felipe Contreras
2020-11-13 8:51 ` Roman Perepelitsa
2020-11-14 0:52 ` Felipe Contreras
2020-11-14 5:41 ` Roman Perepelitsa
2020-11-16 19:41 ` Felipe Contreras
2020-11-16 20:22 ` Roman Perepelitsa
2020-11-17 20:28 ` Felipe Contreras
2020-11-18 22:45 ` Daniel Shahaf
2020-11-22 1:20 ` Felipe Contreras
2020-11-23 4:00 ` Daniel Shahaf
2020-11-23 6:18 ` Felipe Contreras
2020-11-19 2:59 ` Bart Schaefer
2020-11-22 1:50 ` Felipe Contreras
2020-11-17 20:54 ` Bart Schaefer [this message]
2020-11-22 1:49 ` Felipe Contreras
2020-11-23 6:48 ` Bart Schaefer
2020-11-23 7:26 ` Felipe Contreras
2020-11-23 20:26 ` Bart Schaefer
2020-11-23 23:39 ` Felipe Contreras
2020-11-24 0:52 ` Bart Schaefer
2020-11-25 8:46 ` Felipe Contreras
2020-11-27 15:44 ` Daniel Shahaf
2020-11-27 20:49 ` Felipe Contreras
2020-11-27 20:59 ` Daniel Shahaf
2020-11-27 21:33 ` Bart Schaefer
2020-11-27 23:37 ` Daniel Shahaf
2020-11-27 23:45 ` Bart Schaefer
2020-11-28 0:24 ` Bart Schaefer
2020-11-28 7:32 ` Bart Schaefer
2020-11-28 12:05 ` Felipe Contreras
2020-11-12 19:26 ` Bart Schaefer
2020-11-12 21:48 ` Felipe Contreras
2020-11-13 22:17 ` Bart Schaefer
2020-11-14 0:58 ` Felipe Contreras
2020-11-11 18:36 ` Bart Schaefer
2020-11-11 21:08 ` Felipe Contreras
2020-11-11 17:02 ` Peter Stephenson
2020-11-11 18:05 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH+w=7a3vOa2+YXpOS0eCGTr_TGNe1uhPBu+B1Xb_4OmmhJk1A@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=felipe.contreras@gmail.com \
--cc=roman.perepelitsa@gmail.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).