zsh-workers
 help / color / mirror / code / Atom feed
* One possible answer to typeset vs. unset
@ 2020-11-28 19:49 Bart Schaefer
  2020-11-28 20:00 ` Bart Schaefer
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Bart Schaefer @ 2020-11-28 19:49 UTC (permalink / raw)
  To: Zsh hackers list

Those of you who get zsh repository commit messages will have seen
this already.  Rather than send a patch here (yet), I've taken
Daniel's suggestion and created a new branch.  The changes address the
issue that "typeset foo" creates $foo set to an empty string, by
concealing the internal value rather than altering the way internal
values are defaulted.

You can see these changes by checking out the "declarednull" branch.

I did not (yet) introduce an option or emulation control of this,
though I did test a build where it was predicated on emulation, and
the current default behavior is unchanged in that case.

This imposes the following changes, most of which can be amended if desired:

A typeset variable with no assignment triggers NO_UNSET warnings when
the name is used in parameter expansion or math.  Incidentally, there
is no existing test that covers this; that is, NO_UNSET is tested only
with names that have never been declared or names that have been
explicitly unset.

The typeset -AEFHLRTZailux options are applied upon the first
assignment to the variable. Explicit unset before the first assignment
discards all of those properties. If any option is applied to an
existing name, historic behavior is unchanged.

Consequent to the foregoing, the (t) parameter expansion flag prints
nothing until after the first assignment, and the (i) and (I)
subscript flags also print nothing.  I think the latter is one of the
more problematic consequences, especially for some completion
functions.

One that I forgot in the commit log:  The behavior of "typeset foo;
typeset foo" is changed.  Previously the second typeset would output
the current setting of foo:
  foo=''
With these changes, that outputs nothing.  However, once a value has
been assigned the historic behavior is restored, so "typeset foo=bar;
typeset foo" outputs
  foo=bar
Furthermore, "typeset foo; typeset -p foo" outputs only
  typeset foo

The bash behavior of "unset foo; typeset -p foo" is NOT used.  This is
called out as an emulation distinction, not a change.

The test cases have not been updated, so several now fail.  The test
harness has been updated to declare default values, because otherwise
the harness itself is the first thing that breaks.



^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2020-12-23 23:00 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-28 19:49 One possible answer to typeset vs. unset Bart Schaefer
2020-11-28 20:00 ` Bart Schaefer
2020-11-28 20:21 ` Bart Schaefer
2020-12-01  8:54 ` Felipe Contreras
2020-12-03 21:19   ` Bart Schaefer
2020-12-04 11:04     ` Felipe Contreras
2020-12-04 15:49       ` Bart Schaefer
2020-12-04 19:47         ` Bart Schaefer
2020-12-05  0:22           ` Bart Schaefer
2020-12-05  0:28         ` Bart Schaefer
2020-12-05  0:51       ` Bart Schaefer
2020-12-05 22:17         ` Bart Schaefer
2020-12-23 23:00         ` Felipe Contreras
2020-12-02 17:18 ` Vincent Lefevre
2020-12-02 18:03   ` Bart Schaefer

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).