From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20209 invoked from network); 16 May 2001 22:06:14 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 16 May 2001 22:06:14 -0000 Received: (qmail 17165 invoked by alias); 16 May 2001 22:06:06 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14371 Received: (qmail 17142 invoked from network); 16 May 2001 22:06:05 -0000 Date: Wed, 16 May 2001 15:11:37 -0700 (PDT) From: mlandis X-Sender: mlandis@dirm.org To: zsh-workers@sunsite.dk Subject: Re: 4.0.1-pre-4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mlandis It worked when I ran configure with --disable-lfs and recompiled many thanks, Matt On Thu, 17 May 2001, Andrej Borsenkow wrote: > 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 > > > >