From mboxrd@z Thu Jan 1 00:00:00 1970 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes Sender: B.Stephens@isode.com To: Zsh Development Workers Subject: Re: Two questions References: <19990126183201.A27794@fysh.org> <990126223651.ZM26737@candle.brasslantern.com> <19990127105955.A5407@fysh.org> MIME-Version: 1.0 From: Bruce Stephens Date: 27 Jan 1999 11:28:31 +0000 In-Reply-To: Phil Pennock's message of "Wed, 27 Jan 1999 10:59:55 +0000" Message-ID: User-Agent: Gnus/5.070069 (Pterodactyl Gnus v0.69) XEmacs/20.4 (Emerald) X-Mailing-List: 5057 Phil Pennock 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.