Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Bug with unset variables

On Wed, Nov 11, 2020 at 10:04 AM Felipe Contreras <felipe.contreras@xxxxxxxxx> 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.

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

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

Messages sorted by: Reverse Date, Date, Thread, Author