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 Message-ID: <19990127105955.A5407@fysh.org> Date: Wed, 27 Jan 1999 10:59:55 +0000 From: Phil Pennock To: Zsh Development Workers Subject: Re: Two questions Mail-Followup-To: Zsh Development Workers References: <19990126183201.A27794@fysh.org> <990126223651.ZM26737@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2 In-Reply-To: <990126223651.ZM26737@candle.brasslantern.com>; from "Bart Schaefer" on Tue 26 Jan 1999 (22:36 -0800) Organisation: Organisation? Here? No, over there ----> X-Disclaimer: Any views expressed in this message, where not explicitly attributed otherwise, are mine and mine alone. Such views do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. X-Mailing-List: 5055 Typing away merrily, Bart Schaefer produced the immortal words: > On Jan 26, 6:32pm, Phil Pennock wrote: > } Bog-standard Bourne shell handles it smoothly. If we're aiming for > } compatibility, fixing this might be good. How feasible is it? > } > } Eg, > } % cat foo > } #!/path/to/zsh -f > } print >$1 '=== Foo! ===' > > Shouldn't that be > > print >&$1 '=== Foo! ===' > > (note `&')? Otherwise you're redirecting to the file named $1, not to > the descriptor numbered $1. Sorry, yes. Typing in untested code from memory. > tryit() { > echo No parameter 1>&2 > echo Parameter: $1>&$2 > } > > Any of bash, zsh 3.0.5, and zsh-3.1.5-pws-5 give exactly the same result: > The output is correctly redirected to the descriptor on the right-hand > side of the redirection, even when that descriptor is named in a variable, > but a variable on the left-hand side of the redirection simply becomes > another argument to the echo. E.g., Again, yes and sorry. It's when the variable is on the LHS. > Now, are you certain that "bog-standard Bourne shell" does the thing you > wanted with descriptors on both/either sides of the redirection operator? Bleurgh. Okay, my mistake. I failed to do what I wanted in zsh. When someone wanted to know how to do something similar, I checked in sh and that worked. But the working bit was RHS, not LHS. I didn't notice the difference. Pox. What _I_ was wanting was to redirect _from_ an arbitrary descriptor to a file (also an arg). The junk necessary with evals and the like was not something I wanting in the project, so I ended up resorting to a C wrapper with oodles of functionality. ;^) > } Recently zsh has changed a number of things to be more compatible with > } ksh. And some things, such as the associative arrray stuff, has > } followed what seem to be dubious criteria in order to be compatible. > > Could you please describe which "dubious criteria" you mean? Other than > the fact that we now have conflicting meanings of the -A option for some > nominally related commands, I thought we were doing pretty well with the > associative array stuff. That was the main one I was thinking of. And also the hassles with syntax for subscripting and the like. Bart, you were quite vocal at the time. > } Given that there's pdksh for that, just how important is it for zsh to > } parallel ksh? > > Not that I'm really in the compatibily camp, but the argument goes a bit > like this: > > Lots and lots of shell scripts -- particularly system init scripts and > components of GNU utilities -- are written to work with bash and/or ksh. > If zsh can't interpret those scripts, lots of things go wrong; /bin/sh > can't be a link to zsh, some "make" tools that don't properly reset > $(SHELL) will break for people who use zsh, and so forth. Every such > bit of breakage is an obstacle to getting zsh installed and used on the > machine where it happens. In extreme cases there are even disk space > or memory usage issues that limit the number of shells that can be made > available; if zsh can't reliably interpret critical shell scripts, it > will be removed in favor of a shell that can, even if interactive users > suffer as a result. Therefore, zsh must always be a superset of other > Bourne-like shells, not just in function but also in form. Bourne-shell, fine, obviously. Using zsh/emulate as a drop-in replacement for /bin/sh would be wonderful. And adding functionality to mirror other shells is A Good Thing(TM), for instance that ${param/pat/str} stuff from bash just recently. And hey, zsh keeps adding enough new features of its own that it's not-quite into "me too!" competition. But every time something breaks or something goes, just to be like ksh (eg, PWD (& auto-resize?)), zsh loses a part of that which makes it unique. 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. There are a load of ksh scripts out there, but AFAIK mostly only on SysV OSes, where removing ksh isn't a sensible option, no matter how good the emulation. The scripting languages which are winning are Perl, bash and Python. How many people do you know who use the advanced ksh-isms rather than switch to perl or whatever? The only situation that I can currently think of is with systems where installing "free software" is not an option, or where "Perl is a hacking tool" is the motto. Such places aren't going to install zsh, are they? 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"? -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". > } And how important to do so natively, as opposed to an option adding > } behaviour or whatever? > > Here I'm of the opinion that the number of options has already gotten > out of hand and very close scrutiny should be applied to new ones. That > means that if you're adding something that another Bourne-like shell has > already implemented, do it the same way as that other shell UNLESS that > already conflicts with an established zsh usage. In that case only, an > option could be considered (and the established zsh usage should remain > the default). And when the other shell doesn't directly conflict, but leads to confusion in other areas which aren't in the other shell? 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. -- --> Phil Pennock ; GAT d- s+:+ a23 C++(++++) UL++++/I+++/S+++/B++/H+$ P++@$ L+++ E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+ G+ e+ h* r y?