Re: Two questions

[Phil Pennock <comet@xxxxxxxx>]

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?