4.0.1-pre-1

4.0.1-pre-1

[Peter Stephenson]

I have uploaded zsh-4.0.1-pre-1.tar.gz to the archive in the development
subdirectory.

  ftp://ftp.zsh.org/pub/development/zsh-4.0.1-pre-1.tar.gz

and (eventually) mirrors.

Bart's change for nested parameter substitution is still to go in.  Other
than that, the only things missing before a release are any remaining code
for signal queueing (see 13365: I suspect it's already a good deal safer
than in any previous release, however), and minor changes to the
documentation to reflect the new release.

If there are any outstanding bugs you feel still need to be fixed, please
report them again.

The changes since 3.1.9-dev-8 are as follows.


2001-02-02  Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru>

	* 13431: aczsh.m4,configure.in,Src/Modules/termcap.c,
	Src/Modules/termcap.mdd,Src/Modules/terminfo.c,
	Src/Modules/terminfo.mdd,Src/mkmakemod.sh: hopefully better
	check for shared libraries. Link in termcap/terminfo statically
	if shared libtermcap/libcurses unavailable

2001-02-13  Sven Wischnowsky  <wischnow@zsh.org>

	* 13462: Src/Modules/zpty.c: try to make the -t option of zpty
 	smarter
	
	* 13459: Completion/Core/_path_files: wehn using glob_complete,
 	don't treat everything starting with a tilde as a pattern
	
2001-02-12  Bart Schaefer  <schaefer@zsh.org>

	* 13457: Completion/Core/compinit: Add `glob' to $_comp_options.

2001-02-09  Sven Wischnowsky  <wischnow@zsh.org>

	* 13450: Completion/Core/_multi_parts: two small fixes to
 	_multi_parts; one more place where a caller-supplied -S can be
 	used and fix for the code deciding which prefix to use
	
2001-02-08  Oliver Kiddle  <opk@zsh.org>

	* 13448: Completion/User/.distfiles, Completion/User/_tin,
	Completion/User/_netscape, Completion/User/_newsgroups:
	add newsgroup completion

	* 13445: Completion/User/_gzip: fix to work for zcat again

2001-02-07  Bart Schaefer  <schaefer@zsh.org>

	* 13442: Test/Makefile.in, Test/comptest: Run zsh with +Z to
	prevent ZLE modules from being loaded before $module_path is
	changed to point at the test installation.

	* 13439: Test/Makefile.in: "make test" cleans up after killed
	tests.

2001-02-02  Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru>

	* unposted: Src/mkmakemod.sh: patterns in 13412 were wrong.

2001-02-02  Sven Wischnowsky  <wischnow@zsh.org>

	* Peter: 13427: Completion/Core/_expand: fix for handling quoting
 	for filenames with weird characters

2001-02-01  Oliver Kiddle  <opk@zsh.org>

	* 13422: README, Completion/User/_urls, Doc/Zsh/manual.yo,
	Doc/Zsh/metafaq.yo, Etc/CONTRIBUTORS: refer to just sunsite.dk
	instead of sunsite.auc.dk

	* 13420: Completion/User/_tin: new completion function for tin

2001-01-31  Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru>

	* 13412: Src/mkmakemod.sh: avoid duplicate subdirectories in
	recursive build

2001-01-29  Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru>

	* unposted: ChangeLog: typo in previous commit message

2001-01-28 Felix Rosencrantz <f_rosencrantz@yahoo.com>

	* 13395: Test/54compmatch.ztst, Test/comptest: Added code to
	test compstate[insert_positions], value of insert_positions are
	now reported

2001-01-26  Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru>

	* 13389: Src/builtin.c: on Cygwin convert path to posix form in
	cd_do_chdir() to avoid dealing with drives letters

2001-01-25  Sven Wischnowsky  <wischnow@zsh.org>

	* 13388: Src/Zle/compmatch.c: fix for mergin two CLF_MID entries
 	in cline lists (with two equal prefixes it thought there were
 	characters missing)
	
	* 13384: Src/signals.c: make signal queueing variables be exported
 	to modules
	
2001-01-19  Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru>

	* 13370 (modified): Src/params.c: do not modify environment when
	importing it - some library functions may access it. When importing
	colon arrays, replenv() tried to free unallocated memory. Remove
	replenv() as it is now redundant.

	* 13380: configure.in: replace AC_CHECK_LIB(...,tgetent) with
	AC_SEARCH_LIBS(tgetent,...) to allow user to override default
	library selection

2001-01-18  Sven Wischnowsky  <wischnow@zsh.org>

	* 13374: Src/Zle/compcore.c, Src/Zle/compctl.c, Src/Zle/complist.c,
 	Src/Zle/compresult.c, Src/Zle/zle_main.c, Src/Zle/zle_tricky.c:
 	temporarily allow recursive completion when called from menu
 	selection

2001-01-18  Peter Stephenson  <pws@csr.com>

	* 13302: Functions/Zftp/zftp_progress: division by zero

2001-01-16  Sven Wischnowsky  <wischnow@zsh.org>

	* 13365: Src/builtin.c, Src/exec.c, Src/glob.c, Src/hashtable.c,
 	Src/hist.c, Src/init.c, Src/input.c, Src/jobs.c, Src/math.c,
 	Src/mem.c, Src/module.c, Src/params.c, Src/parse.c, Src/prompt.c,
 	Src/signals.c, Src/signals.h, Src/subst.c, Src/utils.c,
 	Src/watch.c, Src/Modules/zftp.c, Src/Modules/zpty.c,
 	Src/Modules/zutil.c, Src/Zle/compcore.c, Src/Zle/complist.c,
 	Src/Zle/computil.c, Src/Zle/zle_main.c, Src/Zle/zle_tricky.c:
 	remove 13108 (trap queues); replace with signal queueing to ensure
 	that user signal handlers are only executed when it is safe to run
 	them
	
	* 13364: Src/Zle/compctl.c: fix for ol' compctl when completing
 	hash keys
	
2001-01-15  Sven Wischnowsky  <wischnow@zsh.org>

	* 13349: Src/Zle/compmatch.c, Src/Zle/compresult.c: two more fixes
 	for completion matching and reporting interesting positions
	
	* Ulrik Haugen: 13344, 13347: Completion/User/_grep,
	Completion/User/_ls, Completion/User/_use_lo: add completion for
	ls and ([ef]|)grep
	
	* 13346: Completion/Bsd/_bsd_pkg, Completion/Bsd/_kld,
 	Completion/Core/_compalso, Completion/Core/_complete,
 	Completion/Core/_normal, Completion/Core/compdump,
 	Completion/Core/compinit, Completion/Debian/_apt,
 	Completion/Debian/_bug, Completion/Debian/_dpkg,
 	Completion/User/_bzip2, Completion/User/_chown,
 	Completion/User/_compress, Completion/User/_dvi,
 	Completion/User/_gzip, Completion/User/_imagemagick,
 	Completion/User/_ispell, Completion/User/_java,
 	Completion/User/_lp, Completion/User/_make,
 	Completion/User/_mount, Completion/User/_mysql_utils,
 	Completion/User/_pack, Completion/User/_pbm,
 	Completion/User/_psutils, Completion/User/_rcs,
 	Completion/User/_rlogin, Completion/User/_ssh,
 	Completion/User/_tiff, Completion/User/_yp, Completion/X/_xutils,
 	Doc/Zsh/compsys.yo: add `services', allowing easier re-use of
 	(parts of) completion functions (see also: 12977)
	
2001-01-12  Sven Wischnowsky  <wischnow@zsh.org>

	* 13343: Src/Zle/compmatch.c, Src/Zle/compresult.c: fix for 13339
 	(report each position only once) and fixlet for matching: a case
 	where missing characters weren't remembered
	
2001-01-11  Sven Wischnowsky  <wischnow@zsh.org>

	* 13339: Doc/Zsh/compwid.yo, Doc/Zsh/contrib.yo,
 	Functions/Zle/cycle-completion-positions, Src/Zle/comp.h,
 	Src/Zle/complete.c, Src/Zle/compresult.c: add
 	unambiguous_positions and insert_positions keys to $compstate; use
 	them in the new cycle-completion-positions shell function widget

2001-01-10  Geoff Wing  <gcw@zsh.org>

	* unposted: Etc/MACHINES: format leading spaces to tabs

2001-01-10  Sven Wischnowsky  <wischnow@zsh.org>

	* 13336: Src/Zle/compmatch.c, Src/Zle/compresult.c,
 	Test/54compmatch.ztst: fix cursor positioning with partial-word
 	match specs using `**'
	
2001-01-08  Sven Wischnowsky  <wischnow@zsh.org>

	* 13331: Src/Zle/compcore.c, Src/Zle/compresult.c: fix for
 	listpacked for matches as long as screen is wide (minus added
 	spaces); more security when freeing matches: make sure current
 	menu match pointer isn't used afterwards
	
2001-01-07  Peter Stephenson  <pws@pwstephenson.fsnet.co.uk>

	* 13327: Etc/MACHINES: builds out of the box on SCO UnixWare
	2.1.3, reported by Josip Rodin <joy@cibalia.gkvk.hr>.

2000-12-27  Clint Adams  <schizo@debian.org>

	* 13315: Completion/User/_killall: strip parentheses and
	path heads.

	* 13314: Completion/User/_killall: ignore commands that begin
	with hyphens (login shells).

2000-12-26  Clint Adams  <schizo@debian.org>

	* 13312: Completion/User/_killall: get longer command names
	from procps.

2000-12-23  Clint Adams  <schizo@debian.org>

	* unposted: configure.in: thinko in jobtable size determination.

	* Chip Salzenberg: 13310: Completion/Debian/_apt:
	correct typo for apt-cache completion.

2000-12-17  Bart Schaefer  <schaefer@zsh.org>

	* Zefram: 13290: Src/Zle/zle_bindings.c, Src/Zle/zle_keymap.c:
	Back out 13285.

2000-12-17  Clint Adams  <schizo@debian.org>

	* 13288: Src/Modules/zftp.c: cast pointers when calling
	ztrapread and ztrapwrite.

	* 13287: Completion/Debian/_dpkg: complete multiple
	arguments for -i.

2000-12-16  Clint Adams  <schizo@debian.org>

	* unposted: Completion/User/.distfiles: add _mere

	* 13285: Src/Zle/zle_bindings.c, Src/Zle/zle_keymap.c:
	use vi-up-line-or-history and vi-down-line-or-history in
	the vicmd keymap (rather than their emacsy counterparts).

2000-12-15  Tanaka Akira  <akr@zsh.org>

	* 13281: Functions/Misc/mere: new implementation.
	Completion/User/_mere: new completion function for mere.

2000-12-13  Clint Adams  <schizo@debian.org>

	* 13250: Completion/User/.distfiles, Completion/User/_dict:
	completion for dict.

2000-12-06  Peter Stephenson  <pws@csr.com>

	* unposted: Src/jobs.c: rename waitjob() to zwaitjob() to avoid
	clash with IRIX system function.

2000-12-06  Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru>

	* 13243: Makefile.in: we do not use Makefile in Completion and
	Functions any more.

2000-12-05  Clint Adams  <schizo@debian.org>

	* 13242: Src/Modules/terminfo.c: better error-checking
	for non-existent capabilities referenced by $terminfo.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

RE: 4.0.1-pre-1

[Andrej Borsenkow]

>
> If there are any outstanding bugs you feel still need to be fixed, please
> report them again.
>

- ^Z does not work under Cygwin
- zpty does not work under Cygwin (not that I care really)
- we had some ideas about function directories layout. Is current the ultimate
one?

-andrej

Re: 4.0.1-pre-1

[Bart Schaefer]

On Feb 14, 12:35pm, Peter Stephenson wrote:
}
} I have uploaded zsh-4.0.1-pre-1.tar.gz to the archive in the development
} subdirectory.

Any particular reason we skipped 4.0.0?

} Bart's change for nested parameter substitution is still to go in.

Does that mean you agree that it should?  What about extending it to ${x=y}?
What about the issues discussed in 13468?

} If there are any outstanding bugs you feel still need to be fixed, please
} report them again.

You should know better than to ask me that ... let's see.  Some of the
following date back two years ...

Not a bug, but nothing ever came of the discussion of MAILCHECK from 6453.

Similarly, there was your (PWS's) parameter wishlist in 6565.

There was a whole thread about "cd" behavior, culminating with 8093.  I
meant to try to look at this and never managed to do so.

We appear to have given up on compadd flags, 8866.

There's the ksh incompatibility with array export, 9576.

Again not a bug, but we discussed making $_is_gnu more generic, 10998.

There's the SIGPIPE issue from 12223 (only partly fixed by 12222?).

Nobody ever even replied (publicly, anyway) to zsh-users/3273, nor to
zsh-users/3363.  They may not represent actual zsh bugs, though.

Andrej reported an associative array subscripting problem in 12484, and
brought up something similar in 12676.

Apparently nobody had any better ideas about 12724.

We never did anything about the thread that includes 12805, 12807, and
12812.

We never did anything about 12834.

Parts of 12867 were covered by 12869, but not all of 12867.

Nothing ever came of 12871.

There were some cygwin issues in 12981, 12982, 12987 that I don't know
whether were ever addressed.  (Andrej?)

Do we care about the tcsh [[ -X name ]] test, users/3450?

There was some discussion of better glob-option handling for _path_files
in 13131.

Andrej has already mentioned 13142 and 13144, though not by number.

Any reason not to do the doc fix suggested in users/3524?

Minor "make *clean" fix was suggested in 13245.

Looking at 13270 reminds me that we should go through the patch and bug
managers on SourceForge and clean things out there, too.

Are we going to accept 13280, or not?

There was an apparent race condition discussed in 13297 and 13298.

I see that Clint's committed 13323, but I'm not convinced that it's the
correct fix.

There's a bug report in 13338 that was never addressed.

And that covers everything that I've been informally keeping track of.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

PATCH: Re: 4.0.1-pre-1

[Peter Stephenson]

> Any particular reason we skipped 4.0.0?

It just felt wrong to have the first release ending in 0 instead of 1.

> Any reason not to do the doc fix suggested in users/3524?
> 
> Minor "make *clean" fix was suggested in 13245.

These are easy.

Index: Makefile.in
===================================================================
RCS file: /cvsroot/zsh/zsh/Makefile.in,v
retrieving revision 1.6
diff -u -r1.6 Makefile.in
--- Makefile.in	2000/12/06 08:28:20	1.6
+++ Makefile.in	2001/02/14 17:47:19
@@ -114,7 +114,7 @@
 @CLEAN_MK@
 
 distclean-here:
-	rm -f Makefile config.h config.status config.log config.cache stamp-h Config/defs.mk
+	rm -f Makefile config.h config.status config.log config.cache config.modules stamp-h Config/defs.mk
 
 realclean-here:
 	cd $(sdir) && rm -f config.h.in stamp-h.in configure
Index: Doc/Zsh/options.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v
retrieving revision 1.12
diff -u -r1.12 options.yo
--- Doc/Zsh/options.yo	2000/08/10 16:19:12	1.12
+++ Doc/Zsh/options.yo	2001/02/14 17:47:19
@@ -343,7 +343,7 @@
 delete the pattern from the argument list;
 do not report an error unless all the patterns
 in a command have no matches.
-Overrides tt(NULL_GLOB).
+Overrides tt(NOMATCH).
 )
 pindex(DVORAK)
 item(tt(DVORAK))(

`make check' error [ Re: 4.0.1-pre-1 ]

[Fletch]

        I get errors from a `make check' on Linux.

[...]

Test ./07cond.ztst failed: bad status 1, expected 0 from:
  ln -s zerolength link
  [[ -h link && ! -h zerolength ]]
Was testing: -h cond
./07cond.ztst: test failed.
This test takes at least three seconds...
This test, too, takes at least three seconds...

[...]

*** /tmp/zsh.ztst.out.14034     Thu Feb 15 09:05:18 2001
--- /tmp/zsh.ztst.tout.14034    Thu Feb 15 09:05:19 2001
***************
*** 2,8 ****
  line: {tst -o +o }{}
  line: {tst -o +o }{}
  MESSAGE:{no arguments}
! line: {tst +o }{}
! line: {tst +o -o }{}
! line: {tst +o -o }{}
  MESSAGE:{no arguments}
--- 2,10 ----
  line: {tst -o +o }{}
  line: {tst -o +o }{}
  MESSAGE:{no arguments}
! line: {tst -+}{}
! MESSAGE:{no arguments}
! line: {tst -+}{}
! MESSAGE:{no arguments}
! line: {tst -+}{}
  MESSAGE:{no arguments}
Test ./55arguments.ztst failed: output differs from expected as shown
above for:
 tst_arguments -+o
 comptest $'tst -\t\t\t\C-w\C-w+\t\t\t'
Was testing: option beginning with + and -.
./55arguments.ztst: test failed.


        Configured with `./configure --prefix=/usr'.  Platform info
(if anything else would be helpful let me know):


Linux rodan.phydeaux.org 2.2.18 #1 Tue Feb 13 21:14:11 EST 2001 i586 unknown
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
glibc-2.1.3-15


        I've gone ahead and done a make install and everything seems
to be working as far as normal interactive use, but I just thought I'd 
mention

-- 
Fletch                | "If you find my answers frightening,       __`'/|
fletch@phydeaux.org   |  Vincent, you should cease askin'          \ o.O'
770 933-0600 x211(w)  |  scary questions." -- Jules                =(___)=
                      |                                               U

Re: 4.0.1-pre-1

[Peter Stephenson]

Ignoring most of the items which are associated with long discussions
(pah!) or the ones which may not even be bugs (pah! pah!):

> There's the ksh incompatibility with array export, 9576.

There's some commented-out code in there in one place already.  I think we
should make ksharrays export the first word and with noksharrays, to be
logical, export the array joined the same way we always get an array as a
single word (c.f. singsub()).  We should make sure we don't export the
array if it's tied to a colon-array.  I don't think we should export
associative arrays at all --- the order is undefined, so we can't guarantee
compatibility with ksh, nor promise a particular form for the non-ksh
exported value.  Unless anyone has ideas.

This needs some work on the addenv() call in typeset_single(), and
some work in export_param(), and some additions to call export_param() from
array code.  It's probably not hard, but it's also absurdly easy to miss
consequent changes in the parameter code.

> There's the SIGPIPE issue from 12223 (only partly fixed by 12222?).

I haven't thought about this since, but after jogging my memory by reading
12223, 12222 is good enough for the real problem, and the rest was just my
paranoia.  The issue was that if a `tee' spawned by a multio exits early,
the parent shell will get SIGPIPE and exit, too; but that's probably not a
bug.

> Andrej reported an associative array subscripting problem in 12484, and
> brought up something similar in 12676.

There is a fairly basic, though not necessarily intractable, difficulty in
parsing associative array subscripts.  There's a (clumsy) workaround using
scalar parameters as the subscript.

I didn't even notice the problem with patterns of the form 'foo?##bar'
before, oops.  (You're expected to use `foo?*bar', but it should still
work.)  There's a fix below --- seems to work, but I've completely
forgotten about the pattern code.

> Apparently nobody had any better ideas about 12724.

Probably a yodl bug.  Well, hope so.

> We never did anything about the thread that includes 12805, 12807, and
> 12812.
>
> We never did anything about 12834.

These are new features, rather than bugs.  Pah.

> Nothing ever came of 12871.

Coprocesses.  Painful.

> There were some cygwin issues in 12981, 12982, 12987 that I don't know
> whether were ever addressed.  (Andrej?)
>
> Andrej has already mentioned 13142 and 13144, though not by number.

I think there are still real problems within cygwin, but it's not that easy
to tell.  Certainly stuff involving pty's and job control is still
sufficiently unlike genuine UNIX to warrant our not diving in without a
good reason.

> Are we going to accept 13280, or not?

Alexandre's :r patch.  I think the answer is now `yes'.

> There was an apparent race condition discussed in 13297 and 13298.

Yup, that's still there.

> There's a bug report in 13338 that was never addressed.

The current cd behaviour is related to the loooong discussion about
following or not following links.  The neatest solution was Zefram's, of
keeping the modes completely separate: either just use the logical $PWD
with no second-guessing, or just pass the system exactly what the user
types in and always ask the system for the current directory.  But this
isn't going to get sorted out in a hurry.

> And that covers everything that I've been informally keeping track of.

Wow.

Index: Src/pattern.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/pattern.c,v
retrieving revision 1.8
diff -u -r1.8 pattern.c
--- Src/pattern.c	2000/05/31 08:56:24	1.8
+++ Src/pattern.c	2001/02/18 00:53:28
@@ -1103,13 +1103,19 @@
      * each time we fail on a non-empty branch, we try the empty branch,
      * which is equivalent to backtracking.
      */
-    if ((flags & P_SIMPLE) && op == P_ONEHASH &&
+    if ((flags & P_SIMPLE) && (op == P_ONEHASH || op == P_TWOHASH) &&
 	P_OP((Upat)patout+starter) == P_ANY) {
 	/* Optimize ?# to *.  Silly thing to do, since who would use
 	 * use ?# ? But it makes the later code shorter.
 	 */
 	Upat uptr = (Upat)patout + starter;
-	uptr->l = (uptr->l & ~0xff) | P_STAR;
+	if (op == P_TWOHASH) {
+	    /* ?## becomes ?* */
+	    uptr->l = (uptr->l & ~0xff) | P_ANY;
+	    pattail(starter, patnode(P_STAR));
+	} else {
+	    uptr->l = (uptr->l & ~0xff) | P_STAR;
+	}
     } else if ((flags & P_SIMPLE) && op && !(patglobflags & 0xff)) {
 	/* Don't simplify if we need to look for approximations. */
 	patinsert(op, starter, NULL, 0);
-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: 4.0.1-pre-1

[Bart Schaefer]

On Feb 17, 12:53am, Peter Stephenson wrote:
} Subject: Re: 4.0.1-pre-1
}
} Ignoring most of the items which are associated with long discussions
} (pah!) or the ones which may not even be bugs (pah! pah!):

We should at least record somewhere (the BUGS file?) those that really
are bugs, so that we don't forget to address them later.

} > There's the ksh incompatibility with array export, 9576.
} 
} There's some commented-out code in there in one place already.  I think we
} should make ksharrays export the first word and with noksharrays, to be
} logical, export the array joined the same way we always get an array as a
} single word (c.f. singsub()).  We should make sure we don't export the
} array if it's tied to a colon-array.  I don't think we should export
} associative arrays at all --- the order is undefined, so we can't guarantee
} compatibility with ksh, nor promise a particular form for the non-ksh
} exported value.  Unless anyone has ideas.

The way ksh appears to treat an unsubscripted associative array reference
is to substitute the element whose hash key is "0".  That is, no matter
what kind of array it is, $array == $array[0].  The associative array
code in getstrvalue() already does this, but only when `emulate ksh' is
in effect (just ksharrays is not enough to activate it).

So one issue is whether `emulation == EMULATE_KSH' should be replaced by
`isset(KSHARRAYS)' in a number of places in params.c.

For noksharrays, I think we should just leave well enough alone and not
export the arrays at all.  The only reason to export one is because you
want to import it again, and tying to a colon-array is a more reliable
way of accomplishing that.  Of course there are joining/splitting issues
either way.

We could export an array as a whole bunch of variables ARRAY[0]=... etc.,
but then some programs (older shells in particular) get all huffy because
the string to the left of the `=' is "not an identifier".

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: 4.0.1-pre-1

[Andrej Borsenkow]

>
> } > There's the ksh incompatibility with array export, 9576.
> }

Speaking about compatibility, bash exports functions (can ksh do this as
well?). I was surprised to see that some people actually use it. The problem
is mostly on Linux, where sh == bash by default, so "sh compatibility" mostly
means "bash comaptibility".

-andrej

exported functions (was Re: 4.0.1-pre-1)

[Oliver Kiddle]

Andrej Borsenkow wrote:

> Speaking about compatibility, bash exports functions (can ksh do this as
> well?). I was surprised to see that some people actually use it. The problem
> is mostly on Linux, where sh == bash by default, so "sh compatibility" mostly
> means "bash comaptibility".

According to the ksh88 manual I have, functions and aliases can be
exported but it doesn't work when I try it. pdksh's manual states that
it did work in the original ksh and that the export attribute of
functions is currently not used. ksh93's manual specically states that
the -x option to alias is obsolete and says nothing about exported
functions. So in short, ksh can't export functions. Note that bash
can't export aliases.

I can't think of many uses for exported functions but wouldn't have any
objections. Bash compatibility isn't that vital to me personally.
Higher on my wish list for new features after 4.0 would be the various
ksh93 features we don't have like variable references, nested variable
assignments and discipline functions.

Oliver

RE: 4.0.1-pre-1

[Andrej Borsenkow]

> 
> Andrej has already mentioned 13142 and 13144, though not by number.
> 

^Z problem fixed in current Cygwin snapshot. Not zpty, sigh ...

-andrej

Re: 4.0.1-pre-1

[Alexandre Duret-Lutz]

Hi!

>>> "Peter" == Peter Stephenson <pws@csr.com> writes:

[...]

 Peter> If there are any outstanding bugs you feel still need to
 Peter> be fixed, please report them again.

[...]

I don't know if this can be considered as an `outstanding bug'
but I haven't seen any mention of zsh-users/3574 in this thread.

I've tried to run that script (testsuite) with Zsh: it takes a
*while* to start (i.e., to parse, I guess), acquires all the
memory, most of the swap, brings the machine to its knees, and
eventually run script as would other shells.  Althought it
actually works, this behavior is quite uncomfortable :)  
Any idea?
-- 
Alexandre Duret-Lutz

Re: 4.0.1-pre-1

[Peter Stephenson]

> I don't know if this can be considered as an `outstanding bug'
> but I haven't seen any mention of zsh-users/3574 in this thread.
> 
> I've tried to run that script (testsuite) with Zsh: it takes a
> *while* to start (i.e., to parse, I guess), acquires all the
> memory, most of the swap, brings the machine to its knees, and
> eventually run script as would other shells.  Althought it
> actually works, this behavior is quite uncomfortable :)  
> Any idea?

I've had other problems, including `\c' not being interpreted by echo,
which is actually deliberate for `emulate sh', and lots of tests failing,
but there's something wrong with setting up here since a lot of tests fail
anyway.  The errors include usage messages from grep and egrep, and errors
from perl, so I don't think I'm going to be going very far as things stand
at the moment.  However, zsh does produce more errors.  I haven't seen
memory problems, though.  Maybe I'll try at home.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: 4.0.1-pre-1

[Alexandre Duret-Lutz]

>>> "Peter" == Peter Stephenson <pws@csr.com> writes:

 >> I don't know if this can be considered as an `outstanding bug'
 >> but I haven't seen any mention of zsh-users/3574 in this thread.
 >> 
 >> I've tried to run that script (testsuite) with Zsh: it takes a
 >> *while* to start (i.e., to parse, I guess), acquires all the
 >> memory, most of the swap, brings the machine to its knees, and
 >> eventually run script as would other shells.  Althought it
 >> actually works, this behavior is quite uncomfortable :)  
 >> Any idea?

 Peter> I've had other problems, including `\c' not being
 Peter> interpreted by echo, which is actually deliberate for
 Peter> `emulate sh', and lots of tests failing, but there's
 Peter> something wrong with setting up here since a lot of
 Peter> tests fail anyway.  The errors include usage messages
 Peter> from grep and egrep, and errors from perl, so I don't
 Peter> think I'm going to be going very far as things stand at
 Peter> the moment.  However, zsh does produce more errors.  I
 Peter> haven't seen memory problems, though.  Maybe I'll try at
 Peter> home.

I don't see what you describe, pass the start the testsuite runs
fine (here).  I have done some more experiments with a fresh Zsh
from today's CVS, compiled with profiling support (although I now
believe it's just a memory consumption problem).

The script run (i.e. the testsuite) as weel as the gprof output
are available here: http://www.epita.fr/~duret_g/zsh-users-3574.tgz

Note that I have modified the testsuite so that it exits right
before the first test (in order to profile only the startup),
display memory usage on exit, and don't require autoconf (grep for
`ADL--' in the file to see the changed points).  The output is
as follow:

~/projs/autoconf-2.49c/tests % zsh testsuite                          14:23 #63
====================================
Testing suite for GNU Autoconf 2.49c
====================================

Some tests might be skipped if you don't have the software which the
macros check (e.g., a Fortran compiler).


Executables (autoheader, autoupdate...).

adl       6648 54.6 85.1 199924 107900 pts/4 S    14:23   0:13 zsh testsuite
adl       6688  0.0  0.3  1320  472 pts/4    S    14:24   0:00 grep testsuite
             total       used       free     shared    buffers     cached
Mem:        126732     124396       2336          0        424      10296
-/+ buffers/cache:     113676      13056
Swap:       244392     123120     121272
~/projs/autoconf-2.49c/tests % free                                   14:24 #64
             total       used       free     shared    buffers     cached
Mem:        126732      19308     107424          0        440      11984
-/+ buffers/cache:       6884     119848
Swap:       244392      37244     207148
~/projs/autoconf-2.49c/tests % ls -l testsuite                        14:24 #65
-rwxr-xr-x    1 adl      lrde       673886 Mar  6 14:23 testsuite*


See how much memory Zsh does acquire.  Actually it takes a
dozen of seconds to run here (not so much) because I have 100Mb
free.  It usually runs in 3-4min in normal conditions (when I have
X, emacs, netscape, etc. loaded).

For what it's worth, here is the head of gprof output:

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 70.02      3.06     3.06   101532     0.03     0.03  zhalloc
  6.41      3.34     0.28    52966     0.01     0.01  ecstrcode
  5.26      3.57     0.23     4101     0.06     0.06  hrealloc
  2.97      3.70     0.13    23756     0.01     0.01  shingetline
  2.06      3.79     0.09    52489     0.00     0.04  gettokstr
  1.60      3.86     0.07   771871     0.00     0.00  ingetc
  1.37      3.92     0.06    93615     0.00     0.02  gettok
  1.14      3.97     0.05   485929     0.00     0.00  add
  1.14      4.02     0.05   105533     0.00     0.00  has_token
  0.69      4.05     0.03       29     1.03    47.01  gettext2
  0.46      4.07     0.02   121251     0.00     0.00  nohw
  0.46      4.09     0.02    93615     0.00     0.03  yylex
  0.46      4.11     0.02    89908     0.00     0.00  inungetc

The full output is in the aforementioned archive.
-- 
Alexandre Duret-Lutz