Re: 4.0.1-pre-4

Re: 4.0.1-pre-4

[mlandis]

Bart said to send this to zsh-workers, so here it is :)

On Wed, 16 May 2001, Bart Schaefer wrote:

> On May 15,  8:06am, Matthew Landis wrote:
> } Subject: 4.0.1-pre-4
> }
> } I apologize if this isn't a suitable question to ask here
> 
> No, this is exactly the right place.
> 
> } I installed 4.0.1-pre-4 yesterday and couldn't get tab completion to work.
> 
> First question:  Did "make check" work when you ran it in the build
> directory?  (Or did you install prepackaged binaries from somewhere?)

I ran make check and it failed on a decent number tests
I ran make clean, configure, and make again and examined all of the output
and saw nothing that looked suspicious.
The errors from make check are as follows:

--------------------------

./A01grammar.ztst: starting.
Test ./A01grammar.ztst failed: bad status 1, expected 0 from:
  echo f*
  noglob echo f*
Error output:
ZTST_execchunk:2: no matches found: f*
Was testing: `noglob' precommand modifier
./A01grammar.ztst: test failed.

--------------------------------------

Test ./A04redirect.ztst failed: bad status 1, expected 0 from:
  rm -f *
  touch out1 out2
  print All files >*
Error output:
ZTST_execchunk:2: no such file or directory:
Was testing: setup multio with globbing
./A04redirect.ztst: test failed.

--------------------------------------

./B01cd.ztst: starting.
*** /tmp/zsh.ztst.out.27380     Wed May 16 10:13:54 2001
--- /tmp/zsh.ztst.tout.27380    Wed May 16 10:13:54 2001
***************
*** 1,2 ****
! /home/mlandis/zsh-4.0.1-pre-4/Test/cdtst.tmp/real
  /home/mlandis/zsh-4.0.1-pre-4/Test/cdtst.tmp/real
--- 1,2 ----
! .
  /home/mlandis/zsh-4.0.1-pre-4/Test/cdtst.tmp/real
Test ./B01cd.ztst failed: output differs from expected as shown above for:
 setopt chaselinks
 cd cdtst.tmp/sub/fake &&
 pwd &&
 print $PWD
Was testing: Resolving symbolic links with chaselinks set
./B01cd.ztst: test failed.

----------------------------------

./C02cond.ztst: starting.
Test ./C02cond.ztst failed: bad status 1, expected 0 from:
  char=(/dev/tty*([1]))
  [[ -c $char && ! -c $block ]]
Error output:
ZTST_execchunk:2: no matches found: /dev/tty*([1])
Was testing: -c cond
./C02cond.ztst: test failed.

---------------------------------

./D02glob.ztst: starting.
Test ./D02glob.ztst failed: bad status 137, expected 0 from:
  ( regress_absolute_path_and_core_dump )
Was testing: exclusions regression test
./D02glob.ztst: test failed.

---------------------------------

./D04parameter.ztst: starting.
*** /tmp/zsh.ztst.out.27647     Wed May 16 10:19:07 2001
--- /tmp/zsh.ztst.tout.27647    Wed May 16 10:19:07 2001
***************
*** 1,2 ****
! * boringfile evenmoreboringfile boringfile evenmoreboringfile
! boringfile evenmoreboringfile
--- 1,2 ----
! *
!
Test ./D04parameter.ztst failed: output differs from expected as shown
above for:
  str1='*'
  print $str1 ${~str1} $~str1
  setopt globsubst
  print $str1
  unsetopt globsubst
Was testing: ${~...} and globsubst
./D04parameter.ztst: test failed.

-----------------------------

(i lost the first few lines of this one)

! DESCRIPTION:{file}
! DI:{dir1}
! DI:{dir2}
! FI:{file1}
! FI:{file2}
! line: {: dir1/}{}
! line: {: dir2/}{}
! line: {: file1}{}
! line: {: file2}{}
! line: {: dir1/}{}
! line: {: dir2/}{}
--- 1,7 ----
  line: {: }{}
! line: {: }{}
! line: {: }{}
! line: {: }{}
! line: {: }{}
! line: {: }{}
! line: {: }{}
Test ./Y01completion.ztst failed: output differs from expected as shown
above for:
  comptest $': \t\t\t\t\t\t\t'
Was testing: directories and files
./Y01completion.ztst: test failed.

-----------------------------

./Y02compmatch.ztst: starting.
*** /tmp/zsh.ztst.out.28186     Wed May 16 10:19:18 2001
--- /tmp/zsh.ztst.tout.28186    Wed May 16 10:19:18 2001
***************
*** 1,3 ****
  line: {tst }{}
- COMPADD:{_tst:compadd: unknown match specification character `z'}
- INSERT_POSITIONS:{}
--- 1 ----
Test ./Y02compmatch.ztst failed: output differs from expected as shown
above for:
 test_code z: list1
 comptest  $'tst \t'
Was testing: Match Error for "z:"
./Y02compmatch.ztst: test failed.

---------------------------------------

./Y03arguments.ztst: starting.
*** /tmp/zsh.ztst.out.28200     Wed May 16 10:19:21 2001
--- /tmp/zsh.ztst.tout.28200    Wed May 16 10:19:22 2001
***************
*** 1,11 ****
! line: {tst arg1 }{}
! line: {tst arg1 }{}
! line: {tst arg1 }{}
! line: {tst arg1 }{}
! line: {tst r}{}
! line: {tst x}{}
! line: {tst x }{}
! MESSAGE:{no more arguments}
! line: {tst x y }{}
! MESSAGE:{no more arguments}
--- 1,9 ----
! line: {tst }{}
! line: {a}{}
! line: {ar}{}
! line: {arg}{}
! line: {arg1}{}
! line: {r}{}
! line: {x}{}
! line: {x }{}
! line: {x y }{}
Test ./Y03arguments.ztst failed: output differs from expected as shown
above for:
 tst_arguments ':desc1:(arg1)'
 comptest $'tst \t\C-wa\t\C-war\t\C-warg\t\C-warg1\t\C-wr\t\C-wx\t \ty \t'
Was testing: one non-option argument
./Y03arguments.ztst: test failed.

-----------------------------------


> 
> (Note that you must "make" before "make check", the check target does
> not rebuild the binary.)
> 
> What operating system and compiler do you have?
debian 2.2 with a 2.4.2 kernel
gcc 2.95.2

> 
> 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.  Please try rebuilding from scratch --
> 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@sunsite.dk>.

I removed the directory, reextracted the tarball, and just did configure /
make / make install

When that didn't fix anything, I tried doing the same with the code from
CVS with the same results

I am using debian 2.2 stable with a 2.4.2 kernel (i586), gcc 2.95.2, and
gave no arguments to configure.



> 
> If that is not the problem, then:
> 
> } 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:
compdump () {
        # undefined
        builtin autoload -XU
}
then there's the definition of compinit and then followed by the above
except with compinstall instead of compdump.
It outputs all of that to the terminal when i do 
autoload -U compinit
compinit


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 / / / / / /".  Once I
do an autoload -U compinit; compinit, the tab key will do nothing.  Trying
to complete a word ("zsh<tab>") either before or after compinit has no
effect.  The * wildcards have the same behavior as described elsewhere in
this email both before and after the compinit.

> 
> } .zcompdump is the following after I run compinit:
> } --------------
> } #files: 372
> } _comps=(
> } )
> } _services=(
> } )
> } 
> } _patcomps=(
> } )
> } 
> } _postpatcomps=(
> } )
> } 
> } _compautos=(
> } )
> } 
> } 
> } autoload -U
> 
> What do you see if you run the command "compaudit"?
> 
> The above is exactly what I get from running "compinit -i" when NONE of
> the completion directories is considered to be secure by compaudit.  If
> compaudit complains, you probably either want to fix the permissions on
> those directories, or else use "compinit -u".

compaudit outputs nothing


> 
> -- 
> Bart Schaefer                                 Brass Lantern Enterprises
> http://www.well.com/user/barts              http://www.brasslantern.com
> 
> Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   
> 

Thanks for any help you can provide,

Matt

Re: 4.0.1-pre-4

[Andrej Borsenkow]

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@sunsite.dk>.
>

> >
> > } 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

Re: 4.0.1-pre-4

[Peter Stephenson]

mlandis wrote:
> ./A01grammar.ztst: starting.
> Test ./A01grammar.ztst failed: bad status 1, expected 0 from:
>   echo f*
>   noglob echo f*
> Error output:
> ZTST_execchunk:2: no matches found: f*
> Was testing: `noglob' precommand modifier
> ./A01grammar.ztst: test failed.

(By the way, I don't think you've mentioned what system this is on yet.)

The globbing failure is the basic problem (maybe not the only one, but the
one to solve first).  This is stupid, but have you tried doing `setopt
glob' before trying a pattern match on files?

Next, does

[[ foo = f* ]] && print "that worked"

work?  If not, it looks like pattern.c wasn't compiled properly.  In that
case, it may be some alignment problem.  You can probe a bit further by
doing

[[ foo = foo ]] && print "it worked that time"

since strings are optimised not to do full pattern matching.  After that,
I'm stuck without some kind of debugger trace.

If the pattern match did work, however, it's probably something wrong with
the file code, maybe something like readdir().  It's nothing to do with
this from Etc/MACHINES, is it?  It's unlikely to be different from
3.1.9-dev-8.

Sun: Solaris 2.*
	The UCB versions of the routines for reading directories are not
	usable (the struct definitions are incompatible with the ones
	assumed by zsh).  The symptom of this is that globbed filenames in
	the compiled version of zsh will be missing the first two letters.
	To avoid this, make sure you compile zsh without any reference
	to /usr/ucblib in your LD_LIBRARY_PATH.  You can easily do this
	by just unsetting LD_LIBRARY_PATH before building zsh.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: 4.0.1-pre-4

[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
> > > <zsh-workers@sunsite.dk>.
> >
> 
> > >
> > > } 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
> 
> 
> 
>