Re: 4.0.1-pre-4

[Andrej Borsenkow <Andrej.Borsenkow@xxxxxxxxxxxxxx>]

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