Re: Two questions

[Bruce Stephens <b.stephens@isode.com>]

Phil Pennock <comet@fysh.org> writes:

> Think ahead three years.  Scenario: bash has programmable
> completion, glob modifiers, associative arrays.  Much of the rest is
> fun, but is it enough to distinguish from the competition?  A
> sysadmin might want the extra features, but justifying them is
> another matter.  If zsh falls into me-too-ism then from a marketing
> point of view it's killing itself.  Every time that we say, "Yes,
> you could do that, but we changed it for compatibility with ksh, so
> now you have to use this workaround" we're detracting from zsh.

A shell which is a better ksh than pdksh would be worth having.  I
agree, zsh is beyond that stage, but even so.  

If bash has all the features that I currently use in zsh (mostly
completion and globbing), then I'll be happy to use bash.

> [...] I'm just worried that zsh is heading down a deadend road.  How
> important _will_ ksh compatibility be three, five, years from now?
> Isn't it more important to make zsh better and do it _right_, with
> as little unnecessary confusion as possible, rather than just "it
> does that too, and is just as bad"?

Compatibility with other shells is a significant convenience.  It
means that in many places, people can choose to use zsh, and still
source initialisation scripts written for lesser shells.  It means
that examples in ksh cookbooks are likely to teach me something about
zsh.

Some incompatibility is OK, though.  The SH_WORD_SPLIT thing springs
to mind.  zsh does this the Right Way, and is deliberately
incompatible in this minor way.

> -a vs -A vs -H vs whatever is just a case in point.  There needs to
> be a clear unambiguous meaning for each, instead of "'-A' means
> associative here, but the option was already taken there, so use
> '-H' instead".

Associative arrays are new to zsh.  I suspect use of them will either
be extensive (if they get used elsewhere, in completion, say) or
pretty minor.  In the former case, the syntax will presumably evolve
to something that's convenient.

> I'm not a key developer, feel free to tell me to get lost or
> whatever.  But IMNSHO some aspects of the ksh associative-array
> syntax suck.  Mightily.

I'm sure that constructive suggestions of associative array syntax
would be looked at.  Probably for this particular aspect of syntax,
compatibility with ksh isn't critical, although other things being
equal, compatibility is better than incompatibility.