Re: Bug with unset variables

[Felipe Contreras <felipe.contreras@gmail.com>]

On Wed, Nov 11, 2020 at 12:36 PM Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Wed, Nov 11, 2020 at 10:04 AM Felipe Contreras <felipe.contreras@gmail.com> wrote:

>> And what is the reason why this is not the default?
>
> Remember that doc Daniel quoted?
>
> 30 years-ish ago, when implementing zsh as a new shell from scratch, that documentation was used to decide the behavior.  At that point the other shells that supported "typeset" were not freeware -- they required expensive licenses or were bundled with commercial operating systems.  So the implementation followed the doc (sometimes, it followed a misunderstanding of the doc, which is why for example zsh syntax to specify integer bases differs from ksh) without examples to which to compare.
>
> Zsh development has always followed a principle of NOT arbitrarily breaking past usage without an extremely good reason (something I wish other APIs would have taken to heart over the years ... IMO there would be much less abandonware sitting in metaphorical dustbins ... but I digress).  So by the time anyone noticed, the behavior you see now was standard practice for zsh in its default modes.

This is *in general* a good principle to follow, and it does indeed
salvage plenty of projects from the dustbin, but that doesn't mean the
rule must be necessarily unquestionably followed.

I argue there almost always is a sweet spot. While almost always it's
bad to break APIs, not changing them ever also sends projects to the
dustbin.

The biggest mistake projects make isn't breaking API, but *how* they
do it. There are few disadvantages of setting a flag to turn on the
new behavior so that people can try it, then enabling the flag by
default, while always leaving the possibility to turn the flag off for
the people that prefer the old behavior.

Doing this once say every 10 years seems like a sensible thing to do.
Just have a list of all these proposed changes so they don't get lost.
That's what major versions are for.

> Your original example can use ${var:-other} if empty string has no explicit meaning in context.

I know, but it does have meaning. It is a suffix, so I want to use a
space by default "${sfx- }", but only $sfx is unset, it can be set
with an empty value, in which case I don't want any suffix.

And it's not even my code, it's bash code I'm trying to emulate and
leverage from zsh.

>> Either way, if "emulate ksh" is supposed to emulate ksh, then it's not
>> working properly in this instance.
>
> Despite the name, "emulate ksh" is not supposed to perfectly emulate ksh.  All it does is change the values of "setopt" to match ksh as closely as possible.  A more complete emulation is achieved by actually starting zsh from a symlink named "ksh" (or one of a few equivalent ways).  Same goes for "sh" and "bash" (although there is little difference for those two).

Right, but if virtually all shells do this, and it is a known
discrepancy, and I'd argue it's the behavior that makes the most
sense, I think it makes sense to have a flag for it.

Cheers.

-- 
Felipe Contreras