From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19368 invoked from network); 16 May 2001 21:11:44 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 16 May 2001 21:11:44 -0000 Received: (qmail 1232 invoked by alias); 16 May 2001 21:11:38 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14369 Received: (qmail 1074 invoked from network); 16 May 2001 21:11:37 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer goliath.siemens.de) Date: Thu, 17 May 2001 01:11:32 +0400 (MSD) From: Andrej Borsenkow X-X-Sender: To: mlandis cc: Subject: Re: 4.0.1-pre-4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 16 May 2001, mlandis wrote: > Was testing: Resolving symbolic links with chaselinks set Broken lstat? > > > > What operating system and compiler do you have? > debian 2.2 with a 2.4.2 kernel > gcc 2.95.2 > glibc version? > > > > I'm going to jump ahead a bit: > > > > } -------------- > > } In addition, the * and ? wildcards do not work. If I do a "ls *" it prints > > } a "ls: : No such file or directory" for each file that * would match. The ? > > } wildcard just gives "no matches found" in all cases that I tried. > > > > Assuming you mean that wildcards don't work anywhere, even when you are > > not attempting completion, then something is very seriously wrong with > > your zsh build. Failure of file globbing would explain most of the rest > > of the problems you describe. It looks like either readdir() or [l]stat() problem. If it were a SVR4 system (or Solaris) I would swear it is well-known -lucb problem. It looks more like readdir() - note, that ls * finds the correct number of files but every one is just an empty string (or some garbage). This also explains why ? does not work - it has to match real file name while * alone does not actually compare anything. Could you please try something like if [[ abcd == ?bc* ]]; then print yes else print no fi to check if wildcards work? I am not familiar with Debian distribution. Is it possible that there are conflicting definitions of readdir? Also, try rebuilding from scratch with --disable-lfs - it may be, that some headers are not 64-bit clean. > > remove your entire old build tree and unpack the tar file again -- and > > if the problem persists send a description of your operating system and > > OS vendor, your compiler, the arguments you gave to "configure", etc. to > > . > > > > > } When I run compinit, it seems to write its code to stdout > > > > What does "write its code to stdout" mean? Do you actually see output of > > some kind on your terminal? > > I think it writes the source code for the function. It outputs a bunch of > zsh code to the screen, beginning with: I have seen it at least once. Remove old compdump; before installing new version remove old zsh functions as well. I cannot remember what was the problem. I wonder what happens if compinit cannot redirect output. > > Before I run compinit, if I try to tab-complete nothing ("ls "), it > will complete to /. If I continue hitting tab ("ls ", > etc), the command line will begin to look like "ls / / / / / /". again smells very much of readdir. > > > > } .zcompdump is the following after I run compinit: > > } -------------- > > } #files: 372 > > } _comps=( > > } ) If it cannot find any file, it cannot put anything in. Ah, yes, now I remember - my problem was messed up installation so none of the functions were installed. In this case IIRC compinit writes to terminal (instead of file) for whatever reason. I never bothered enough to debug. -andrej