Re: 4.0.1-pre-4

[mlandis <mlandis@xxxxxxxx>]

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
> > > <zsh-workers@xxxxxxxxxx>.
> >
> 
> > >
> > > } 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 <tab>"), it
> > will complete to /.  If I continue hitting tab ("ls <tab><tab><tab>",
> > 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
> 
> 
> 
>