* 4.0.1-pre-1
@ 2001-02-14 12:35 Peter Stephenson
2001-02-14 12:55 ` 4.0.1-pre-1 Andrej Borsenkow
` (3 more replies)
0 siblings, 4 replies; 16+ messages in thread
From: Peter Stephenson @ 2001-02-14 12:35 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: 4.0.1-pre-1
2001-02-14 12:35 4.0.1-pre-1 Peter Stephenson
@ 2001-02-14 12:55 ` Andrej Borsenkow
2001-02-14 17:32 ` 4.0.1-pre-1 Bart Schaefer
` (2 subsequent siblings)
3 siblings, 0 replies; 16+ messages in thread
From: Andrej Borsenkow @ 2001-02-14 12:55 UTC (permalink / raw)
To: Zsh hackers list
>
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 4.0.1-pre-1
2001-02-14 12:35 4.0.1-pre-1 Peter Stephenson
2001-02-14 12:55 ` 4.0.1-pre-1 Andrej Borsenkow
@ 2001-02-14 17:32 ` Bart Schaefer
2001-02-14 17:50 ` PATCH: 4.0.1-pre-1 Peter Stephenson
` (2 more replies)
2001-02-15 14:21 ` `make check' error [ Re: 4.0.1-pre-1 ] Fletch
2001-03-06 8:44 ` 4.0.1-pre-1 Alexandre Duret-Lutz
3 siblings, 3 replies; 16+ messages in thread
From: Bart Schaefer @ 2001-02-14 17:32 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* PATCH: Re: 4.0.1-pre-1
2001-02-14 17:32 ` 4.0.1-pre-1 Bart Schaefer
@ 2001-02-14 17:50 ` Peter Stephenson
2001-02-17 0:53 ` 4.0.1-pre-1 Peter Stephenson
2001-03-06 7:57 ` 4.0.1-pre-1 Andrej Borsenkow
2 siblings, 0 replies; 16+ messages in thread
From: Peter Stephenson @ 2001-02-14 17:50 UTC (permalink / raw)
To: Zsh hackers list
> 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))(
^ permalink raw reply [flat|nested] 16+ messages in thread
* `make check' error [ Re: 4.0.1-pre-1 ]
2001-02-14 12:35 4.0.1-pre-1 Peter Stephenson
2001-02-14 12:55 ` 4.0.1-pre-1 Andrej Borsenkow
2001-02-14 17:32 ` 4.0.1-pre-1 Bart Schaefer
@ 2001-02-15 14:21 ` Fletch
2001-03-06 8:44 ` 4.0.1-pre-1 Alexandre Duret-Lutz
3 siblings, 0 replies; 16+ messages in thread
From: Fletch @ 2001-02-15 14:21 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 4.0.1-pre-1
2001-02-14 17:32 ` 4.0.1-pre-1 Bart Schaefer
2001-02-14 17:50 ` PATCH: 4.0.1-pre-1 Peter Stephenson
@ 2001-02-17 0:53 ` Peter Stephenson
2001-02-18 1:43 ` 4.0.1-pre-1 Bart Schaefer
2001-03-06 7:57 ` 4.0.1-pre-1 Andrej Borsenkow
2 siblings, 1 reply; 16+ messages in thread
From: Peter Stephenson @ 2001-02-17 0:53 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 4.0.1-pre-1
2001-02-17 0:53 ` 4.0.1-pre-1 Peter Stephenson
@ 2001-02-18 1:43 ` Bart Schaefer
2001-02-19 6:15 ` 4.0.1-pre-1 Andrej Borsenkow
0 siblings, 1 reply; 16+ messages in thread
From: Bart Schaefer @ 2001-02-18 1:43 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: 4.0.1-pre-1
2001-02-18 1:43 ` 4.0.1-pre-1 Bart Schaefer
@ 2001-02-19 6:15 ` Andrej Borsenkow
2001-02-19 22:00 ` exported functions (was Re: 4.0.1-pre-1) Oliver Kiddle
0 siblings, 1 reply; 16+ messages in thread
From: Andrej Borsenkow @ 2001-02-19 6:15 UTC (permalink / raw)
To: Zsh hackers list
>
> } > 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* exported functions (was Re: 4.0.1-pre-1)
2001-02-19 6:15 ` 4.0.1-pre-1 Andrej Borsenkow
@ 2001-02-19 22:00 ` Oliver Kiddle
0 siblings, 0 replies; 16+ messages in thread
From: Oliver Kiddle @ 2001-02-19 22:00 UTC (permalink / raw)
To: Zsh hackers list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: 4.0.1-pre-1
2001-02-14 17:32 ` 4.0.1-pre-1 Bart Schaefer
2001-02-14 17:50 ` PATCH: 4.0.1-pre-1 Peter Stephenson
2001-02-17 0:53 ` 4.0.1-pre-1 Peter Stephenson
@ 2001-03-06 7:57 ` Andrej Borsenkow
2 siblings, 0 replies; 16+ messages in thread
From: Andrej Borsenkow @ 2001-03-06 7:57 UTC (permalink / raw)
To: Bart Schaefer, Zsh hackers list
>
> Andrej has already mentioned 13142 and 13144, though not by number.
>
^Z problem fixed in current Cygwin snapshot. Not zpty, sigh ...
-andrej
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 4.0.1-pre-1
2001-02-14 12:35 4.0.1-pre-1 Peter Stephenson
` (2 preceding siblings ...)
2001-02-15 14:21 ` `make check' error [ Re: 4.0.1-pre-1 ] Fletch
@ 2001-03-06 8:44 ` Alexandre Duret-Lutz
2001-03-06 10:31 ` 4.0.1-pre-1 Peter Stephenson
3 siblings, 1 reply; 16+ messages in thread
From: Alexandre Duret-Lutz @ 2001-03-06 8:44 UTC (permalink / raw)
To: zsh-workers; +Cc: Akim Demaille
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 4.0.1-pre-1
2001-03-06 8:44 ` 4.0.1-pre-1 Alexandre Duret-Lutz
@ 2001-03-06 10:31 ` Peter Stephenson
2001-03-06 14:24 ` 4.0.1-pre-1 Alexandre Duret-Lutz
0 siblings, 1 reply; 16+ messages in thread
From: Peter Stephenson @ 2001-03-06 10:31 UTC (permalink / raw)
To: Zsh hackers list
> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 4.0.1-pre-1
2001-03-06 10:31 ` 4.0.1-pre-1 Peter Stephenson
@ 2001-03-06 14:24 ` Alexandre Duret-Lutz
0 siblings, 0 replies; 16+ messages in thread
From: Alexandre Duret-Lutz @ 2001-03-06 14:24 UTC (permalink / raw)
To: Peter Stephenson; +Cc: Zsh hackers list, Akim Demaille
>>> "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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 4.0.1-pre-1
@ 2001-02-16 14:56 Sven Wischnowsky
0 siblings, 0 replies; 16+ messages in thread
From: Sven Wischnowsky @ 2001-02-16 14:56 UTC (permalink / raw)
To: zsh-workers
Bart Schaefer wrote:
> ...
>
> We appear to have given up on compadd flags, 8866.
Yes, at least I have (although I admit that I had completely forgotten
about this). There are already several people out there who have used
one of the 3.1.x versions. Not many of them will have used compadd,
though.
> ...
>
> Again not a bug, but we discussed making $_is_gnu more generic, 10998.
This still sounds like a good idea, but there wasn't any discussion.
And there's more to this, as I've just discovered, while looking
through the guide. It has to do with services. They should allow one
to say:
compdef myzcat=zcat
to make completion for myzcat do exactly the same as for zcat. And it
almost works, but _zcat uses $_is_gnu and tries calling $words[1] for
that. If the myzcat really behaves like the GNU-zcat this might be
ok, but maybe it doesn't duplicate its behaviour enough to make the
test succeed even if it otherwise allows (almost) the same as the
GNU-version. One could say that the user then gets what he deserves
(for not using `compdef myzcat=gzcat'), but I thought I should at
least mention it here...
The patch below, btw, has to do with services, too. The `compdef myzcat=gzcat'
didn't really work because gzcat itself uses the service `gunzip' and
compdef didn't test that. It does now.
> ...
>
> There was some discussion of better glob-option handling for _path_files
> in 13131.
Hmhm. I think I was just too tired at the time.
Just as a reminder, it's about bareglobquals being unset by the user.
To handle this we would have to make _main_complete store that option
setting where _path_files can look at it. That raises the question if
we should make _main_complete save all previous option settings in
some hash. And then we could remove _(un|)set_options (and the
remarks about them from the manual and the Guide) and make _options
use a style to decide if it should use only set or unset options.
With the parameter module saving the option settings is much less
expensive than it was when we decided not to do that. Is anyone
against making these changes?
> ...
>
> There was an apparent race condition discussed in 13297 and 13298.
I still can't reproduce that.
Bye
Sven
Index: Completion/Core/compinit
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/compinit,v
retrieving revision 1.15
diff -u -r1.15 compinit
--- Completion/Core/compinit 2001/02/13 03:16:55 1.15
+++ Completion/Core/compinit 2001/02/16 14:42:52
@@ -249,6 +249,7 @@
cmd="${i%%\=*}"
svc="${i#*\=}"
func="$_comps[${(k)_services[(R)$svc]:-$svc}]"
+ (( $+_services[$svc] )) && svc=$_services[$svc]
[[ -z "$func" ]] &&
func="${_patcomps[(K)$svc][1]:-${_postpatcomps[(K)$svc][1]}}"
if [[ -n "$func" ]]; then
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: 4.0.1-pre-1
2001-02-14 13:43 4.0.1-pre-1 Sven Wischnowsky
@ 2001-02-15 6:30 ` Andrej Borsenkow
0 siblings, 0 replies; 16+ messages in thread
From: Andrej Borsenkow @ 2001-02-15 6:30 UTC (permalink / raw)
To: zsh-workers
> >
> > - ^Z does not work under Cygwin
> > - zpty does not work under Cygwin (not that I care really)
>
> Hm.
>
Please understand correctly. It is most probably Cygwin problem or (even
worse) some Windows "feature". It means finding your way through several MBs
of Cygwin sources or several GBs of MSDN docs. As long as zpty is almost
exclusively used for test suite only, it does not look like high priority
issue.
^Z should be fixed of course, if it is Zsh bug.
-andrej
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: 4.0.1-pre-1
@ 2001-02-14 13:43 Sven Wischnowsky
2001-02-15 6:30 ` 4.0.1-pre-1 Andrej Borsenkow
0 siblings, 1 reply; 16+ messages in thread
From: Sven Wischnowsky @ 2001-02-14 13:43 UTC (permalink / raw)
To: zsh-workers
Andrej Borsenkow wrote:
> > 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)
Hm.
> - we had some ideas about function directories layout. Is current the ultimate
> one?
No it isn't.
My original suggestion is in 11097 (and see the follow'ups). I still
like that and it didn't trigger many remarks, or only constructive ones
(of course we now have some more functions but all of these should be
easy to place in the right directories). I don't remember in what way
we decided to do the change in cvs (add/remove?). And noone
volunteered to actually do that, yet ;-)
About Peter's question: the only things I have on my list is a) the
signal stuff Peter mentioned, b) the completion position stuff
discussed with Felix (I haven't found an easy way to make this smarter
and so have given up for now; for every solution I could see now I
would have to touch more places than seems worth, i.e. this is nothing
that should stop us from 4.0) and c) helping Peter to bring The Guide
up-to-date (esp. chapter 6, of course).
What kept me from working on a) and c) is that they are rather tedious
tasks (although I have marked the/some places for c) in a printed
copy) and that we had to hold one of the courses for the third
semester: 230 students and only two assistants, urgh. But the latter
is almost finished now.
So I hope to find the time to look at them this week or weekend.
Bye
Sven
P.S.: I just love it that the _bash_completions are in section 6.6.6
in The Guide ;-)
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2001-03-06 14:18 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-02-14 12:35 4.0.1-pre-1 Peter Stephenson
2001-02-14 12:55 ` 4.0.1-pre-1 Andrej Borsenkow
2001-02-14 17:32 ` 4.0.1-pre-1 Bart Schaefer
2001-02-14 17:50 ` PATCH: 4.0.1-pre-1 Peter Stephenson
2001-02-17 0:53 ` 4.0.1-pre-1 Peter Stephenson
2001-02-18 1:43 ` 4.0.1-pre-1 Bart Schaefer
2001-02-19 6:15 ` 4.0.1-pre-1 Andrej Borsenkow
2001-02-19 22:00 ` exported functions (was Re: 4.0.1-pre-1) Oliver Kiddle
2001-03-06 7:57 ` 4.0.1-pre-1 Andrej Borsenkow
2001-02-15 14:21 ` `make check' error [ Re: 4.0.1-pre-1 ] Fletch
2001-03-06 8:44 ` 4.0.1-pre-1 Alexandre Duret-Lutz
2001-03-06 10:31 ` 4.0.1-pre-1 Peter Stephenson
2001-03-06 14:24 ` 4.0.1-pre-1 Alexandre Duret-Lutz
2001-02-14 13:43 4.0.1-pre-1 Sven Wischnowsky
2001-02-15 6:30 ` 4.0.1-pre-1 Andrej Borsenkow
2001-02-16 14:56 4.0.1-pre-1 Sven Wischnowsky
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).