Two questions

Two questions

[Sven Wischnowsky]

I have been having trouble with configuring and make for some time
now...

1) We have this extra hack in configure to change config.status to
   treat filenames starting with `!' specially. This fails utterly for 
   me, because it searches for a line where `ac_file_inputs' is
   assigned to -- and my config.status doesn't contain such a line.
   It always uses `$ac_given_srcdir/$ac_file_in'.
   Up to now I've always been hacking this by hand, but...

2) make distclean fails for me because it calls distclean twice in the 
   Test directory -- and then the second one has no Makefile and I end 
   up with the main directory un-cleaned.
   This can be fixed by removing:

	@cd Test && $(MAKE) $(MAKEDEFS) $@

   from the distclean-here target in the Makefile.in from the main
   directory. Is this correct or am I the only one with this problem?
   But somehow I think this is a result of the patch that added Test
   to SUBDIRS, yes?


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Two questions

[Bart Schaefer]

On Apr 6, 10:39am, Sven Wischnowsky wrote:
} Subject: Two questions
}
} 1) We have this extra hack in configure to change config.status to
}    treat filenames starting with `!' specially. This fails utterly for 
}    me, because it searches for a line where `ac_file_inputs' is
}    assigned to -- and my config.status doesn't contain such a line.
}    It always uses `$ac_given_srcdir/$ac_file_in'.

What version of autoconf do you have installed?  I think you need at least
2.12, maybe 2.13, for this to work.  Peter has 2.14, IIRC, but I have 2.13
and I have the ac_file_inputs line in my config.status.

} 2) make distclean fails for me because it calls distclean twice in the 
}    Test directory -- and then the second one has no Makefile and I end 
}    up with the main directory un-cleaned.
}    This can be fixed by removing:
} 
} 	@cd Test && $(MAKE) $(MAKEDEFS) $@

You're right, that should have been removed when Test was added to SUBDIRS.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

RE: Two questions

[Andrej Borsenkow]

> 
> What version of autoconf do you have installed?  I think you 
> need at least
> 2.12, maybe 2.13, for this to work.  Peter has 2.14, IIRC, 
> but I have 2.13
> and I have the ac_file_inputs line in my config.status.
> 

2.14?? When was it released?

-andrej

Two Questions

[Nikolai Weibull]

Question 1
----------

How do I post to zsh-users as I am only subscribed to this list and thus
need to confirm my emails to zsh-users?  Is the only way to work with it
to confirm?  Since the lists are nested, subscribing to both is not very
good.

Question 2
----------

This should have gone to zsh-users but still.  Is there any way to
disable equals completion (the -equals- context)?  Since I have noequals
set it's rather silly to have the completion system trying to expand it.
I tried figuring out a way to check for '-o equals' somewhere but didn't
come up with anything decent.
	nikolai

--
::: name: Nikolai Weibull    :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: www.pcppopper.org  :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: Two questions

[Zefram]

Bart Schaefer wrote:
>(1) I've forgotten where those filenames starting with `!' are used, and
>there's no mention of it in INSTALL or Etc/zsh-development-guide, nor in
>"configure --help" output, nor any of the other obvious places I looked.
>Will somebody who does remember what it means please document it?

Patch below.  I also added a section on the development tools that are
required, to document the version requirement on autoconf.

>(2) Relying on the ability to edit config.status is bad news to begin with.
>There must be some other way to deal with this?

There isn't.  I tried everything more reasonable first; there really is
no better way to handle this problem.

-zefram

Index: ChangeLog
===================================================================
RCS file: /cvsroot/zsh/zsh/ChangeLog,v
retrieving revision 1.26
diff -c -r1.26 ChangeLog
*** ChangeLog	2000/04/06 12:46:29	1.26
--- ChangeLog	2000/04/06 16:38:53
***************
*** 1,3 ****
--- 1,9 ----
+ 2000-04-06  Andrew Main  <zefram@zsh.org>
+ 
+ 	* zefram1: configure.in, Etc/zsh-development-guide: List of tools
+ 	required for development work, and a little more conspicuous
+ 	explanation of the config.status hack.
+ 
  2000-04-06  Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
  
  	* 10543: Makefile.in: avoid distcleaning Test twice
Index: configure.in
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.in,v
retrieving revision 1.1.1.65
diff -c -r1.1.1.65 configure.in
*** configure.in	2000/03/25 18:04:48	1.1.1.65
--- configure.in	2000/04/06 16:38:58
***************
*** 1607,1613 ****
  [test -z "$CONFIG_HEADERS" || echo > stamp-h])
  
  dnl The standard config.status is missing some essential features.
! dnl So add them now.
  [rm -f $CONFIG_STATUS.old
  cp $CONFIG_STATUS $CONFIG_STATUS.old
  sed '1,$s@^\( *ac_file_inputs=\).*$@\1`echo $ac_file_in | sed -e "s%^%:%" -e "s%:\\([^!]\\)% $ac_given_srcdir/\\1%g" -e "s%:!% %"`@' \
--- 1607,1613 ----
  [test -z "$CONFIG_HEADERS" || echo > stamp-h])
  
  dnl The standard config.status is missing some essential features.
! dnl So add them now.  See the comment at the end of Src/mkmakemod.sh.
  [rm -f $CONFIG_STATUS.old
  cp $CONFIG_STATUS $CONFIG_STATUS.old
  sed '1,$s@^\( *ac_file_inputs=\).*$@\1`echo $ac_file_in | sed -e "s%^%:%" -e "s%:\\([^!]\\)% $ac_given_srcdir/\\1%g" -e "s%:!% %"`@' \
Index: Etc/zsh-development-guide
===================================================================
RCS file: /cvsroot/zsh/zsh/Etc/zsh-development-guide,v
retrieving revision 1.1.1.10
diff -c -r1.1.1.10 zsh-development-guide
*** Etc/zsh-development-guide	1999/12/16 14:26:28	1.1.1.10
--- Etc/zsh-development-guide	2000/04/06 16:39:05
***************
*** 12,17 ****
--- 12,34 ----
  are very simple and hopefully should make for a more orderly development
  of zsh.
  
+ Tools
+ -----
+ 
+ To develop (as opposed to just build) zsh, you'll need a few specialised
+ tools:
+ 
+ * GNU autoconf, version 2.12 or later.  (Earlier versions mostly work,
+   but part of the configuration system now relies on part of the format
+   of the config.status files that get generated.  See the comments in
+   configure.in and at the end of Src/mkmakemod.sh for an explanation.)
+ 
+ * GNU m4.  (Required by autoconf.)
+ 
+ * yodl.
+ 
+ * texi2html.
+ 
  Patches
  -------
  
END

Re: Two questions

[Bart Schaefer]

On Apr 6, 12:42pm, Sven Wischnowsky wrote:
} Subject: Re: Two questions
}
} Bart Schaefer wrote:
} > On Apr 6, 10:39am, Sven Wischnowsky wrote:
} > }
} > } 1) We have this extra hack in configure to change config.status to
} > }    treat filenames starting with `!' specially. This fails utterly for 
} > }    me, because it searches for a line where `ac_file_inputs' is
} > }    assigned to -- and my config.status doesn't contain such a line.
} > 
} > What version of autoconf do you have installed?
} 
} 2.10. We should then mention somewhere that one needs at least version 
} <whatever> somewhere.

Two responses:

(1) I've forgotten where those filenames starting with `!' are used, and
there's no mention of it in INSTALL or Etc/zsh-development-guide, nor in
"configure --help" output, nor any of the other obvious places I looked.
Will somebody who does remember what it means please document it?

(2) Relying on the ability to edit config.status is bad news to begin with.
There must be some other way to deal with this?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Two questions

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Apr 6, 10:39am, Sven Wischnowsky wrote:
> } Subject: Two questions
> }
> } 1) We have this extra hack in configure to change config.status to
> }    treat filenames starting with `!' specially. This fails utterly for 
> }    me, because it searches for a line where `ac_file_inputs' is
> }    assigned to -- and my config.status doesn't contain such a line.
> }    It always uses `$ac_given_srcdir/$ac_file_in'.
> 
> What version of autoconf do you have installed?  I think you need at least
> 2.12, maybe 2.13, for this to work.  Peter has 2.14, IIRC, but I have 2.13
> and I have the ac_file_inputs line in my config.status.

2.10. We should then mention somewhere that one needs at least version 
<whatever> somewhere.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Two questions

[Bart Schaefer]

On Jan 27, 10:59am, Phil Pennock wrote:
} Subject: Re: Two questions
}
} Typing away merrily, Bart Schaefer produced the immortal words:
} > On Jan 26,  6:32pm, Phil Pennock wrote:
} > } 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.

I just read back through the whole thread.  The place where I thought ksh
was "daft" was in the nameref syntax, ${!ref}, and its extension to the
associative array syntax, ${!assoc[@]}.  And what those of you on the zsh
mailing list didn't see was that Tim and I carried on the nameref thread
privately, and it turns out ksh isn't quite as daft as I thought:  It has
completely separate namespaces for namerefs and parameters, though it is
a bit strange in that you seemingly can't ever un-set a nameref.

Anyway, zsh 3.1.5-pws-[45] doesn't use the ${!assoc[@]} syntax except when
"setopt ksharrays" which seems to me exactly the sort of thing that both
of us have been advocating.

} [...] 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.

I'm not terribly concerned about bits that make zsh unique, but I'm in
complete agreement about breaking things.  There ought to be *extremely*
good reasons for introducing any change that breaks my dotfiles or makes
me interact with zsh differently.  There have been several such changes
over the past few years that didn't meet my criteria for "*extremely*
good reason," but little of that applies to the addition of entirely new
features borrowed from elsewhere.

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

I agree again, but please keep in mind that 3.1.x is the development
version of zsh.  In the case of, for example, the PWD/OLDPWD changes,
I'm sure the effect on autonamedirs was simply an oversight.  That's
one of the problems with zsh having so many options and doodads, you
can't tell what a seemingly innocuous change is going to impinge upon.
The important thing is not that PWD et al. be "special" variables, but
that we get the problem resolved before 3.1.x becomes the "official"
3.2.0 release.

The auto-resize stuff, BTW, got changed in response to a different bug
report, which IIRC had something to do with (a) windows resizing when
a job was in the foreground so zsh wasn't listening, and (b) improper
settings of the window size in termcap entries, which zsh believed in
preference to believing the LINES and COLUMNS variables.  It happens
that the fix may have gone too far in the other direction, and then in
turn that 3.0.5 and 3.1.5 didn't stay in sync on the patches.  The
latter is a problem with having separate "production" and "development"
versions, particularly when they've diverged as far as 3.0/3.1 have.

} 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".

There have been cases in the past where an option (like -m) was co-opted
(sorry) to have the same meaning (glob pattern follows) across a range of
commands, even if it already had some other meaning for some of them.

} > [...] 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.
} 
} And when the other shell doesn't directly conflict, but leads to
} confusion in other areas which aren't in the other shell?

Depends on how bad the confusion is, really.  Clarity certainly should be
among the criteria.

} I'm not a key developer, feel free to tell me to get lost or whatever.

We try not to do that.  Everybody's opinion counts for something.

} But IMNSHO some aspects of the ksh associative-array syntax suck.
} Mightily.

Can you list them?  Is it just that `set -A' and `typeset -A' don't have
congruent meanings?  What else?  (When you say "associative array syntax"
I think of $foo[bar] and relations, which really is already as close to
standard zsh array-variable syntax as it can reasonably get.)

On Jan 27, 11:28am, Bruce Stephens wrote:
} Subject: Re: Two questions
}
} 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 think that was pretty much Phil's point -- he doesn't want you to be
as happy to use bash as you are to use zsh.  Zsh should have the edge
on happiness.

On Jan 27,  1:46pm, Peter Stephenson wrote:
} Subject: Re: Two questions
}
} I rely on Bart for the look and feel angle.

Well, thanks.  (Speaking of happiness, *I'd* certainly be a lot happier
if all the maintainers had done that, but ....)

On Jan 27,  2:11pm, Phil Pennock wrote:
} Subject: Re: Two questions
}
} Personally, I think that Bart was correct in his judgement and that ksh
} is daft in this respect.  Bart, any chance of restoring 'typeset -H' and
} making 'typeset -A' (was it?) a compatibility way in, for ksh
} compatibility?

It could be special-cased.  The way `typeset' works, the position of the
option letter in a string determines the bit that gets turned on in a
flag word, so it requires extra code to have two letters that mean the
same flag.

It'd also be possible (maybe even easier) to add a declarator like the
`integer' and `local' commands, distinguished on the command name.

} Generally, the array/Associative array thing could do with becoming an
} array/Hash thing.  And sorting out what needs to be in 'set' and what in
} 'typeset'.

Let me say that I was actually happy about changing `typeset -H' to `-A'
because I don't like referring to associative arrays as "hashes".  They
happen to be implemented that way, but there's no reason they have to be,
and the term "hash" (and the command name `hash') is already taken in zsh
to refer to various command and filesystem mapping-related things.

I personally dislike the choice of -H for the option you added to `stat',
for exactly this reason.  But I don't use the stat module, so I didn't
bother to complain.

} This is a user-interface thing as much as anything else, so
} any one person declaring correctness wouldn't be as good as discussion
} and consensus (hence these posts).

Yes.

} PS: did anything ever come of adding namerefs?

No, nothing has come of that.  It's not particularly necessary in zsh,
because you can do this:

zsh% ref='$param'
zsh% param='This is the value of param'
zsh% echo ${(e)ref}
This is the value of param

The only reasons for adding namerefs would be ksh compatibility and to get
the separate namespace.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Two questions

[Phil Pennock]

Typing away merrily, Bruce Stephens produced the immortal words:
> > 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.

I don't have my archives with me, but looking through the web-based
archives, I can verify that my memory is correct (A Good Thing given the
redirect fiasco).  Also I don't have access to the pws-patched versions
at the moment.  *sigh*

Bart introduced the associative array stuff with some reasonably clean
syntax, all things considered.  It was changed to be compatible with
ksh.  <http://www.zsh.org/mla/workers/1998/msg00925.html> shows that he
used 'typeset -H'.

Personally, I think that Bart was correct in his judgement and that ksh
is daft in this respect.  Bart, any chance of restoring 'typeset -H' and
making 'typeset -A' (was it?) a compatibility way in, for ksh
compatibility?  Doesn't need an option to enable it, just documented,
perhaps deprecated, and all examples using the cleaner 'typeset -H'.

Generally, the array/Associative array thing could do with becoming an
array/Hash thing.  And sorting out what needs to be in 'set' and what in
'typeset'.  This is a user-interface thing as much as anything else, so
any one person declaring correctness wouldn't be as good as discussion
and consensus (hence these posts).

The other 'issue' is something I'd need to check on before making an
utter fool of myself again.  ;^)

And to quote the article that started this, from Bruce Stephens,
<http://www.zsh.org/mla/workers/1998/msg00927.html>:
>What does ksh93 provide in the way of associative array functionality?
>(I don't have it installed at work, so I can't look it up right not.)
>
>I'm not suggesting that ksh93 is always right about everything, but it
>would surely be a good starting point, and a zsh which contained ksh93
>as a subset would be much more convenient than having gratuitous
>syntactic differences.  Except in those places where ksh93 is just
>wrong, of course.

I'm inclined to agree with that last sentence.  :^)

PS: did anything ever come of adding namerefs?
-- 
--> 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?

Re: Two questions

[Peter Stephenson]

Geoff Wing wrote:
> Phil Pennock <comet@fysh.org> typed:
> :I'm not a key developer,
> 
> Who are these ``key developer''s?  We just have
> 1) a bunch of general users submitting changes, releasing them on the
>    (unsuspecting *) beta testers, then sending patches to fix the
>    typos/brainos/whatever.
> 
> (* unsuspecting if you're naive :-) )

A `key developer' is defined as a non-unsuspecting beta tester who
also submits patches, I suppose.

> 2) a coordinator (or, as now, pro tem. coordinator) who somehow gets all
>    those patches which look/sound/feel OK to not collide.

Pro tem., mainly on sound.  I rely on Bart for the look and feel angle.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Two questions

[Bruce Stephens]

mason@primenet.com.au (Geoff Wing) writes:

> Phil Pennock <comet@fysh.org> typed:
> :I'm not a key developer,
> 
> Who are these ``key developer''s?  We just have
> 1) a bunch of general users submitting changes, releasing them on the
>    (unsuspecting *) beta testers, then sending patches to fix the
>    typos/brainos/whatever.
> 2) a coordinator (or, as now, pro tem. coordinator) who somehow gets all
>    those patches which look/sound/feel OK to not collide.

Sure, but there are a few people who actually do this, and rather more
of us who foolishly download the code and merely complain about it.
(And all of us, of course, occasionally praise it, often in terms like
"Good grief, I didn't know it could do *that*.  Heck, it's even in the
documentation.  How have I missed that for years?".)

Re: Two questions

[Bruce Stephens]

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.

Re: Two questions

[Geoff Wing]

Phil Pennock <comet@fysh.org> typed:
:I'm not a key developer,

Who are these ``key developer''s?  We just have
1) a bunch of general users submitting changes, releasing them on the
   (unsuspecting *) beta testers, then sending patches to fix the
   typos/brainos/whatever.
2) a coordinator (or, as now, pro tem. coordinator) who somehow gets all
   those patches which look/sound/feel OK to not collide.

(* unsuspecting if you're naive :-) )

:feel free to tell me to get lost or whatever.

Regards,
-- 
Geoff Wing   <gcw@pobox.com>            Mobile : (Australia) 0412 162 441
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

Re: Two questions

[Phil Pennock]

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?

Re: Two questions

[Bart Schaefer]

On Jan 26,  6:32pm, Phil Pennock wrote:
} Subject: Two questions
}
} A few weeks ago I queried (on zsh-users) how to do redirection from a
} variable file descriptor.  The answer was quite complex, and boiled down
} to the fact that the parser gets in the way.
} 
} 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.

} % ./foo 5 5>Funky

I just tried the following little function:

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

    zagzig% tryit 5 1
    No parameter
    Parameter: 5
    zagzig% tryit 2 5
    No parameter
    zsh: 5: bad file number
    zagzig% tryit 2 5 5>/dev/null
    No parameter
    zagzig%

Now, are you certain that "bog-standard Bourne shell" does the thing you
wanted with descriptors on both/either sides of the redirection operator?

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

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

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

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Two questions

[Phil Pennock]

Hi, a quick two questions (new job, no access to sources atm)

A few weeks ago I queried (on zsh-users) how to do redirection from a
variable file descriptor.  The answer was quite complex, and boiled down
to the fact that the parser gets in the way.

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! ==='
% ./foo 5 5>Funky

This is a little contrived, but effectively what:
 (a) I needed at the time
 (b) What someone else on another list needed - being able to redirect
     to and from arbitrary fds.

Second question:

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.
Given that there's pdksh for that, just how important is it for zsh to
parallel ksh?  And how important to do so natively, as opposed to an
option adding behaviour or whatever?

TIA
-- 
--> 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?