Bug#663982: zsh: autocompletion does not work anymore after compinit
Am Donnerstag, 22. März 2012 schrieb Frank Terbeck: Martin Steigerwald wrote: auto completion stopped worked since this week. This might be related to an upgrade of Z-Shell. It is related configuration, with an empty .zshrc it works. But with the recommended configuration from the system administrator it does not. I found it to stop working after compinit. With empty configuration: mango% cd Infrastruktur/ [aborted with Ctrl-C] mango% autoload -Uz compinit mango% cd Infrastruktur/ [aborted with Ctrl-C] Before you're running `compinit', the function-based completion system is *NOT* online yet. Zsh will fall back to the older compctl system. mango% compinit mango% cd In No reaction on tab anymore. When you say no reaction do you mean that zsh eats up all CPU or does it actually hang without and CPU utilisation at all? I see no / or not much CPU utilisation. When I enter cd Intr and then press tab, I get the following strace: ms@mango:~ strace -fF -p 8220 Process 8220 attached - interrupt to quit read(10, \t, 1) = 1 fcntl64(0, F_DUPFD, 10) = 11 close(0)= 0 mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb73d7000 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0 mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb73d3000 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 open(/dev/null, O_RDONLY|O_NOCTTY|O_LARGEFILE) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 [… lots more of these …] munmap(0xb73d3000, 16384) = 0 munmap(0xb73d7000, 16384) = 0 dup2(11, 0) = 0 close(11) = 0 write(10, \7, 1) = 1 read(10, ^C unfinished ... Process 8220 detached File descriptors are as follows: ms@mango:/proc/8220 ls -l fd insgesamt 0 lrwx-- 1 ms teamix 64 Mär 26 09:37 0 - /dev/pts/13 lrwx-- 1 ms teamix 64 Mär 26 09:41 1 - /dev/pts/13 lrwx-- 1 ms teamix 64 Mär 26 09:41 10 - /dev/pts/13 lrwx-- 1 ms teamix 64 Mär 26 09:41 2 - /dev/pts/13 ms@mango:/proc/8220 That mmap2 seems to be related to the completion shared object: ms@mango:/proc/8220 pmap -d 8220 | head -2 ; pmap -d 8220 | grep b73d 8220: /usr/bin/zsh Address Kbytes Mode Offset DeviceMapping b73db000 132 r-x-- 009:1 complete.so So basically Z-Shell seems to be doing nothing it seems to me. But this only happens for *one* user that uses a home directory on NFS. If NFS is in play it could also be bad performance with certain options. Does the shell hang or does completion just take a very very long time? As in minutes? It just does not seem to occur at all. The Konsole tab with the zsh process 8220 is still sitting at cd Infr as if I didn't hit the tab key at all. Neither with root nor with a local user I can reproduce this. Tab completion worked for the NFS user as well before. I can fix it by uncommenting compinit from his .zshrc. Sounds weird. Can't identify a reason off hand. Welcome to the club ;). This is the .zshrc of the user, but as said it also does not work with the system admin recommended one. [...] There is nothing in there, that would cause that I think. The other files (zshenv, zprofile, zlogin - global and user-only) are empty, I presume? Yes, empty besides comments or not existing excdept for some path setting: ms@mango:~ find -maxdepth 1 -name .zsh* ./.zshrc-empty ./.zshrc-off ./.zshrc ./.zshrc-sysadm ./.zsh_history mango:~# cat /etc/zsh/zshenv # /etc/zsh/zshenv: system-wide .zshenv file for zsh(1). [… comments …] if [[ -z $PATH || $PATH == /bin:/usr/bin ]] then export PATH=/usr/local/bin:/usr/bin:/bin:/usr/games fi mango:~# grep -v ^# /etc/zsh/zlogin mango:~# grep -v ^# /etc/zsh/zprofile mango:~# I didn't touch any of these AFAIR. Even with this configuration auto completion does not work for the autocd case. But for the local test user it works also in the autocd case. For the local test user it also works when I navigate on the NFS export. My
Bug#663982: [Pkg-zsh-devel] Bug#663982: zsh: autocompletion does not work anymore after compinit
Am Donnerstag, 22. März 2012 schrieb Axel Beckert: Hi, Frank Terbeck wrote: Martin Steigerwald wrote: auto completion stopped worked since this week. This might be related to an upgrade of Z-Shell. It is related configuration, with an empty .zshrc it works. But with the recommended configuration from the system administrator it does not. I found it to stop working after compinit. With empty configuration: mango% cd Infrastruktur/ [aborted with Ctrl-C] mango% autoload -Uz compinit mango% cd Infrastruktur/ [aborted with Ctrl-C] […] mango% compinit mango% cd In No reaction on tab anymore. […] But this only happens for *one* user that uses a home directory on NFS. If NFS is in play it could also be bad performance with certain options. Does the shell hang or does completion just take a very very long time? As in minutes? I ran into this too, after I bumped my zshrc to the newest grml zshrc on Debian Stable with NFS home and about 5000 users in NIS. So I'm not sure if it has the same reason, but it definitely has the same symptoms. I'd say 5 to 10 minutes or so. Ctrl-C doesn't help. Just waiting. The zsh process is in the uninterruptable sleep state (aka D aka disk waiting). No D state here at all: ms@mango:~ ps aux | grep 8220 | grep -v grep ms8220 0.0 0.0 5760 2568 pts/13 Ss 09:37 0:00 /usr/bin/zsh I checked it while pressing tab with ms@mango:~ watch -n 0,1 ps aux | grep 8220 | grep -v grep in a different window. It doesn't seem to happen with all kinds of completion but at least with scp completion. I always happens with the LDAP user, even on non-NFS: ms@mango:/etc cd netw [… aborted by Ctrl-C …] My *guess* is that something triggers user-name lookups which may take a very long time with a lot of users in networked environments. But like I said, it's a guess for now... I think the direction is the right one... We don't have a lot of users, maybe 50 at most. Ciao, -- Martin Steigerwald - teamix GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663982: [Pkg-zsh-devel] Bug#663982: Bug#663982: zsh: autocompletion does not work anymore after compinit
Am Donnerstag, 22. März 2012 schrieb Michael Prokop: * Axel Beckert [Thu Mar 22, 2012 at 11:27:54AM +0100]: Frank Terbeck wrote: Martin Steigerwald wrote: [...] mango% compinit mango% cd In No reaction on tab anymore. [...] I ran into this too, after I bumped my zshrc to the newest grml zshrc on Debian Stable with NFS home and about 5000 users in NIS. So I'm not sure if it has the same reason, but it definitely has the same symptoms. I'd say 5 to 10 minutes or so. Ctrl-C doesn't help. Just waiting. The zsh process is in the uninterruptable sleep state (aka D aka disk waiting). It doesn't seem to happen with all kinds of completion but at least with scp completion. Might be worth trying a debug session as documented in http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=blob;f=debian/RE ADME.Debian I need some instruction on what to step, what to next and what to skip since it takes ages to single step through that Z-Shell is doing when I press tab. Or is there some way to let gdb just capture whats happening and put it into a log file that I can attach here? Ciao, -- Martin Steigerwald - teamix GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663982: [Pkg-zsh-devel] Bug#663982: Bug#663982: zsh: autocompletion does not work anymore after compinit
Am Donnerstag, 22. März 2012 schrieb Michael Prokop:
* Axel Beckert [Thu Mar 22, 2012 at 11:27:54AM +0100]:
Frank Terbeck wrote:
Martin Steigerwald wrote:
[...]
mango% compinit
mango% cd In
No reaction on tab anymore.
[...]
I ran into this too, after I bumped my zshrc to the newest grml zshrc
on Debian Stable with NFS home and about 5000 users in NIS. So I'm not
sure if it has the same reason, but it definitely has the same
symptoms.
I'd say 5 to 10 minutes or so. Ctrl-C doesn't help. Just waiting. The
zsh process is in the uninterruptable sleep state (aka D aka disk
waiting).
It doesn't seem to happen with all kinds of completion but at least
with scp completion.
Might be worth trying a debug session as documented in
http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=blob;f=debian/RE
ADME.Debian
Here is what I get when I just next through it. Thats just what happens when
I press tab in a shell with compinit loaded where tab completion does not
work:
ms@mango:~/lokal/Debian/zsh-debugging#1 gdb $(find . -type d -printf '-d %p ')
attach 8463
GNU gdb (GDB) 7.4-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
attach: Datei oder Verzeichnis nicht gefunden.
Attaching to process 8463
Reading symbols from /bin/zsh4...Reading symbols from
/usr/lib/debug/bin/zsh4.dbg...done.
done.
Reading symbols from /lib/libcap.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcap.so.2
Reading symbols from /lib/i386-linux-gnu/i686/cmov/libdl.so.2...Reading
symbols from /usr/lib/debug/lib/i386-linux-gnu/i686/cmov/libdl-2.13.so...done.
done.
[…]
Reading symbols from /usr/lib/zsh/4.3.17/zsh/terminfo.so...Reading symbols
from /usr/lib/debug/usr/lib/zsh/4.3.17/zsh/terminfo.so.debug...done.
done.
Loaded symbols for /usr/lib/zsh/4.3.17/zsh/terminfo.so
[…]
(gdb) step
Single stepping until exit from function __kernel_vsyscall,
which has no line number information.
getbyte (do_keytmout=0, timeout=0x0) at ../../../Src/Zle/zle_main.c:845
845 restore_queue_signals(q);
(gdb) next
846 if (r == -2) {
(gdb) next
845 restore_queue_signals(q);
(gdb) next
846 if (r == -2) {
(gdb) next
852 if (r == 1)
(gdb) next
894 if (cc == '\r') /* undo the exchange of \n and \r
determined by */
(gdb) next
896 else if (cc == '\n')
(gdb) next
905 if (vichgflag) {
(gdb) next
910 errno = old_errno;
(gdb) next
911 return lastchar = ret;
(gdb) next
912 }
(gdb) next
getkeybuf (w=0) at ../../../Src/Zle/zle_keymap.c:1486
1486if(c 0)
(gdb) next
1484int c = getbyte((long)w, NULL);
(gdb) next
1486if(c 0)
(gdb) next
1488if(keybuflen + 3 keybufsz)
(gdb) next
1490if(imeta(c)) {
(gdb) next
1494keybuf[keybuflen++] = c;
(gdb) next
1495keybuf[keybuflen] = 0;
(gdb) next
getkeymapcmd (km=0x8ce18d8, funcp=0xbfb149f4, strp=0xbfb149f8) at
../../../Src/Zle/zle_keymap.c:1431
1431int loc = !!localkeymap;
(gdb) next
1428while(getkeybuf(!!lastlen) != EOF) {
(gdb) next
1431int loc = !!localkeymap;
(gdb) next
1434if (loc) {
(gdb) next
1432int ispfx = 0;
(gdb) next
1439f = keybind(km, keybuf, s);
(gdb) next
1440ispfx |= keyisprefix(km, keybuf);
(gdb) next
1439f = keybind(km, keybuf, s);
(gdb) next
1440ispfx |= keyisprefix(km, keybuf);
(gdb) next
1442if (f != t_undefinedkey) {
(gdb) next
1443lastlen = keybuflen;
(gdb) next
1445str = s;
(gdb) next
1446lastc = lastchar;
(gdb) next
1443lastlen = keybuflen;
(gdb) next
1446lastc = lastchar;
(gdb) next
1445str = s;
(gdb) next
1446lastc = lastchar;
(gdb) next
1448if (!ispfx)
(gdb) next
1451if(!lastlen keybuflen)
(gdb) next
1454lastchar = lastc;
(gdb) next
1455if(lastlen != keybuflen) {
(gdb) next
1454lastchar = lastc;
(gdb) next
1455if(lastlen != keybuflen) {
(gdb) next
1462*funcp = func;
(gdb) next
1463*strp = str;
(gdb) next
1462*funcp = func;
(gdb) next
1463*strp = str;
(gdb) next
1464return keybuf;
(gdb) next
1465}
(gdb) next
getkeycmd () at ../../../Src/Zle/zle_keymap.c:1521
1521if(!*seq)
(gdb) next
1523if(!func) {
(gdb) next
1537if (func == Th(z_executenamedcmd) !statusline) {
(gdb) next
1547if (func ==
Bug#663982: zsh: autocompletion does not work anymore after compinit
Martin Steigerwald wrote: auto completion stopped worked since this week. This might be related to an upgrade of Z-Shell. It is related configuration, with an empty .zshrc it works. But with the recommended configuration from the system administrator it does not. I found it to stop working after compinit. With empty configuration: mango% cd Infrastruktur/ [aborted with Ctrl-C] mango% autoload -Uz compinit mango% cd Infrastruktur/ [aborted with Ctrl-C] Before you're running `compinit', the function-based completion system is *NOT* online yet. Zsh will fall back to the older compctl system. mango% compinit mango% cd In No reaction on tab anymore. When you say no reaction do you mean that zsh eats up all CPU or does it actually hang without and CPU utilisation at all? But this only happens for *one* user that uses a home directory on NFS. If NFS is in play it could also be bad performance with certain options. Does the shell hang or does completion just take a very very long time? As in minutes? Neither with root nor with a local user I can reproduce this. Tab completion worked for the NFS user as well before. I can fix it by uncommenting compinit from his .zshrc. Sounds weird. Can't identify a reason off hand. This is the .zshrc of the user, but as said it also does not work with the system admin recommended one. [...] There is nothing in there, that would cause that I think. The other files (zshenv, zprofile, zlogin - global and user-only) are empty, I presume? [...] Even with this configuration auto completion does not work for the autocd case. But for the local test user it works also in the autocd case. For the local test user it also works when I navigate on the NFS export. My *guess* is that something triggers user-name lookups which may take a very long time with a lot of users in networked environments. But like I said, it's a guess for now... Sorry for taking so long. I'm pretty swamped with other work right now. I hope the other guys from the maintenance team will chime in. ;-) Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663982: [Pkg-zsh-devel] Bug#663982: zsh: autocompletion does not work anymore after compinit
Hi, Frank Terbeck wrote: Martin Steigerwald wrote: auto completion stopped worked since this week. This might be related to an upgrade of Z-Shell. It is related configuration, with an empty .zshrc it works. But with the recommended configuration from the system administrator it does not. I found it to stop working after compinit. With empty configuration: mango% cd Infrastruktur/ [aborted with Ctrl-C] mango% autoload -Uz compinit mango% cd Infrastruktur/ [aborted with Ctrl-C] Before you're running `compinit', the function-based completion system is *NOT* online yet. Zsh will fall back to the older compctl system. mango% compinit mango% cd In No reaction on tab anymore. When you say no reaction do you mean that zsh eats up all CPU or does it actually hang without and CPU utilisation at all? But this only happens for *one* user that uses a home directory on NFS. If NFS is in play it could also be bad performance with certain options. Does the shell hang or does completion just take a very very long time? As in minutes? I ran into this too, after I bumped my zshrc to the newest grml zshrc on Debian Stable with NFS home and about 5000 users in NIS. So I'm not sure if it has the same reason, but it definitely has the same symptoms. I'd say 5 to 10 minutes or so. Ctrl-C doesn't help. Just waiting. The zsh process is in the uninterruptable sleep state (aka D aka disk waiting). It doesn't seem to happen with all kinds of completion but at least with scp completion. My *guess* is that something triggers user-name lookups which may take a very long time with a lot of users in networked environments. But like I said, it's a guess for now... I think the direction is the right one... Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663982: [Pkg-zsh-devel] Bug#663982: Bug#663982: zsh: autocompletion does not work anymore after compinit
* Axel Beckert [Thu Mar 22, 2012 at 11:27:54AM +0100]: Frank Terbeck wrote: Martin Steigerwald wrote: [...] mango% compinit mango% cd In No reaction on tab anymore. [...] I ran into this too, after I bumped my zshrc to the newest grml zshrc on Debian Stable with NFS home and about 5000 users in NIS. So I'm not sure if it has the same reason, but it definitely has the same symptoms. I'd say 5 to 10 minutes or so. Ctrl-C doesn't help. Just waiting. The zsh process is in the uninterruptable sleep state (aka D aka disk waiting). It doesn't seem to happen with all kinds of completion but at least with scp completion. Might be worth trying a debug session as documented in http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=blob;f=debian/README.Debian regards, -mika- signature.asc Description: Digital signature
Bug#663982: zsh: autocompletion does not work anymore after compinit
Hi, Michael Prokop wrote: It doesn't seem to happen with all kinds of completion but at least with scp completion. Might be worth trying a debug session as documented in http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=blob;f=debian/README.Debian Done on Debian Squeeze with zsh 4.3.10-14 and my zsh setup (https://github.com/xtaran/zshrc) at commit 04dcdf0f. It does not happen with just zsh -f on the very same machine. Current working directory was my home directory. It contains one file starting with User: ~ → ls -l User* -rw-r--r-- 1 abe isg 124416 Mar 22 2007 Users-Updated.xls ~ → mount | grep abe xxx-xxx-xxx:/export/home1/A/abeon /home/abe type nfs (rw,sync,tcp,nolock,rsize=32768,wsize=32768,sloppy,addr=129.132.xx.xx) In the shell in question I typed scp -p UserTab, waited some seconds and then pressed Ctrl-C in gdb: (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x7f823ee588d8 in *__GI___poll (fds=0x7fff242ba3e0, nfds=1, timeout=value optimized out) at ../sysdeps/unix/sysv/linux/poll.c:83 83 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. in ../sysdeps/unix/sysv/linux/poll.c (gdb) bt #0 0x7f823ee588d8 in *__GI___poll (fds=0x7fff242ba3e0, nfds=1, timeout=value optimized out) at ../sysdeps/unix/sysv/linux/poll.c:83 #1 0x7f823ee8862e in clntudp_call (cl=0x13666e0, proc=5, xargs=value optimized out, argsp=value optimized out, xresults=value optimized out, resultsp=0x10 Address 0x10 out of bounds, utimeout=...) at clnt_udp.c:374 #2 0x7f823dfccb3e in __ypclnt_call (domain=value optimized out, prog=1, xargs=0x1388, req=0x Address 0x out of bounds, xres=0x1368358, resp=0x10 Address 0x10 out of bounds, ydb=0x7fff242ba488, print_error=1) at ypclnt.c:293 #3 0x7f823dfcd481 in do_ypcall (domain=0x7f823e1dd3a0 phys.ethz.ch, prog=value optimized out, xargs=value optimized out, req=value optimized out, xres=0x7f823dfcc490 *__GI_xdr_ypresp_key_val, resp=0x7fff242ba4e0 ) at ypclnt.c:352 #4 0x7f823dfcd4f9 in do_ypcall_tr (domain=0x7fff242ba3e0 \005, prog=1, xargs=0x1388, req=0x Address 0x out of bounds, xres=0x1368358, resp=0x10 Address 0x10 out of bounds) at ypclnt.c:384 #5 0x7f823dfcdcdf in yp_next (indomain=0x7fff242ba3e0 \005, inmap=value optimized out, inkey=value optimized out, inkeylen=value optimized out, outkey=0x7fff242ba5b0, outkeylen=0x7fff242ba5c8, outval=0x7fff242ba5b8, outvallen=0x7fff242ba5cc) at ypclnt.c:565 #6 0x7f823e1e566b in internal_nis_getpwent_r (result=0x7f823f0f2ca0, buffer=0x1372720 mdidone, buflen=1024, errnop=0x7f823fbb76a8) at nss_nis/nis-pwd.c:253 #7 _nss_nis_getpwent_r (result=0x7f823f0f2ca0, buffer=0x1372720 mdidone, buflen=1024, errnop=0x7f823fbb76a8) at nss_nis/nis-pwd.c:348 #8 0x7f823ee748e0 in __nss_getent_r (getent_func_name=0x7f823eebab49 getpwent_r, setent_func_name=value optimized out, lookup_fct=0x7f823ee74b70 *__GI___nss_passwd_lookup2, nip=0x7f823f0f2d60, startp=value optimized out, last_nip=value optimized out, stayopen_tmp=0x0, res=0, resbuf=0x7f823f0f2ca0, buffer=0x1372720 mdidone, buflen=1024, result=0x7fff242ba718, h_errnop=0x0) at getnssent_r.c:171 #9 0x7f823ee33746 in __getpwent_r (resbuf=value optimized out, buffer=value optimized out, buflen=value optimized out, result=0x58) at ../nss/getXXent_r.c:162 #10 0x7f823ee74503 in __nss_getent (func=0x7f823ee336b0 __getpwent_r, resbuf=0x7f823f0f2ca0, buffer=0x7f823f0f0df8, buflen=value optimized out, buffer_size=0x7f823f0f2cd0, h_errnop=0x0) at getnssent.c:38 #11 0x7f823ee33372 in getpwent () at ../nss/getXXent.c:84 #12 0x0043547d in fillnameddirtable (ht=value optimized out) at ../../Src/hashtable.c:1355 #13 0x7f823d54f39a in scanpmuserdirs (ht=value optimized out, func=0x1, flags=5000) at ../../../Src/Modules/parameter.c:1471 #14 0x004369a8 in scanmatchtable (ht=0x7fff242ba3e0, pprog=0x0, sorted=value optimized out, flags1=0, flags2=33554432, scanfunc=0x459930 scancountparams, scanflags=34) at ../../Src/hashtable.c:381 #15 0x004369d9 in scanhashtable (ht=0x7fff242ba3e0, sorted=value optimized out, flags1=value optimized out, flags2=value optimized out, scanfunc=value optimized out, scanflags=value optimized out) at ../../Src/hashtable.c:444 #16 0x0045cb81 in paramvalarr (ht=0x7fff242ba3e0, flags=34) at ../../Src/params.c:562 #17 0x0045cc67 in getvaluearr (v=0x7fff242bab00) at ../../Src/params.c:584 #18 0x0045cce5 in getarrvalue (v=0x7fff242ba3e0) at ../../Src/params.c:2089 #19 0x7f823d969d3e in get_data_arr (name=0x7f823fbd76a0 , keys=value optimized out) at ../../../Src/Zle/compcore.c:1941 #20 0x7f823d96cddb in addmatches (dat=0x7fff242badf0, argv=0x7fff242baf58) at ../../../Src/Zle/compcore.c:2355 #21 0x7f823d966df0 in bin_compadd
Bug#663982: zsh: autocompletion does not work anymore after compinit
Package: zsh Version: 4.3.17-1 Severity: important Dear Maintainer, auto completion stopped worked since this week. This might be related to an upgrade of Z-Shell. It is related configuration, with an empty .zshrc it works. But with the recommended configuration from the system administrator it does not. I found it to stop working after compinit. With empty configuration: mango% cd Infrastruktur/ [aborted with Ctrl-C] mango% autoload -Uz compinit mango% cd Infrastruktur/ [aborted with Ctrl-C] mango% compinit mango% cd In No reaction on tab anymore. But this only happens for *one* user that uses a home directory on NFS. Neither with root nor with a local user I can reproduce this. Tab completion worked for the NFS user as well before. I can fix it by uncommenting compinit from his .zshrc. This is the .zshrc of the user, but as said it also does not work with the system admin recommended one. ms@mango:~ cat .zshrc # History HISTFILE=~/.histfile HISTSIZE=1000 SAVEHIST=1000 # Optionen setopt sharehistory autocd beep extendedglob correct unsetopt nomatch # Tastaturbelegung bindkey -e # Prompt PROMPT=%(!,,%n@)%m:%~%(?,,#%?) # Automatische Vervollständigung #zstyle :compinstall filename '/home/ms/.zshrc' # Z-Shell Vervollständigung autoload -Uz compinit # With compinit not commented out tab completion does not work #compinit # Less-Eingabe-Vorverarbeitung eval $(lesspipe) # Less-Optionen export LESS=$LESS -w [… exports and aliases …] Even with this configuration auto completion does not work for the autocd case. But for the local test user it works also in the autocd case. For the local test user it also works when I navigate on the NFS export. I know it sounds strange, but this is what I observed. Thanks, Martin -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (450, 'unstable'), (110, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages zsh depends on: ii libc6 2.13-27 ii libcap21:2.22-1 ii libtinfo5 5.9-4 Versions of packages zsh recommends: ii libc6 2.13-27 ii libncursesw5 5.9-4 ii libpcre3 8.12-4 Versions of packages zsh suggests: pn zsh-doc none -- debconf information: * zsh/rcmove: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
