* Re: 4.0.1-pre-4 [not found] <1010516163856.ZM14873@candle.brasslantern.com> @ 2001-05-16 20:44 ` mlandis 2001-05-16 21:11 ` 4.0.1-pre-4 Andrej Borsenkow 2001-05-16 22:07 ` 4.0.1-pre-4 Peter Stephenson 0 siblings, 2 replies; 4+ messages in thread From: mlandis @ 2001-05-16 20:44 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 4.0.1-pre-4 2001-05-16 20:44 ` 4.0.1-pre-4 mlandis @ 2001-05-16 21:11 ` Andrej Borsenkow 2001-05-16 22:11 ` 4.0.1-pre-4 mlandis 2001-05-16 22:07 ` 4.0.1-pre-4 Peter Stephenson 1 sibling, 1 reply; 4+ messages in thread From: Andrej Borsenkow @ 2001-05-16 21:11 UTC (permalink / raw) To: mlandis; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 4.0.1-pre-4 2001-05-16 21:11 ` 4.0.1-pre-4 Andrej Borsenkow @ 2001-05-16 22:11 ` mlandis 0 siblings, 0 replies; 4+ messages in thread From: mlandis @ 2001-05-16 22:11 UTC (permalink / raw) To: zsh-workers 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 > > > > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 4.0.1-pre-4 2001-05-16 20:44 ` 4.0.1-pre-4 mlandis 2001-05-16 21:11 ` 4.0.1-pre-4 Andrej Borsenkow @ 2001-05-16 22:07 ` Peter Stephenson 1 sibling, 0 replies; 4+ messages in thread From: Peter Stephenson @ 2001-05-16 22:07 UTC (permalink / raw) To: mlandis, Zsh hackers list 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-05-16 22:06 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1010516163856.ZM14873@candle.brasslantern.com> 2001-05-16 20:44 ` 4.0.1-pre-4 mlandis 2001-05-16 21:11 ` 4.0.1-pre-4 Andrej Borsenkow 2001-05-16 22:11 ` 4.0.1-pre-4 mlandis 2001-05-16 22:07 ` 4.0.1-pre-4 Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).