Latest patched development version

Latest patched development version

[Peter Stephenson]

I have put a new patched version of zsh 3.1.5 at

http://www.ifh.de/~pws/computing/zsh-3.1.5-pws-3.tar.gz

(the previous file zsh-3.1.5-patched.tar.gz has now disappeared).
It has the version number 3.1.5-pws-3 even though 1 and 2 weren't
numbered.  The following is a list of additions since the previous
version.  I am being less conservative than Zefram will presumably be
when 3.1.6 appears (I notice Zefram's keeping very quiet).  Note in
particular zftp, which is by no means guaranteed to compile on all
machines yet; there isn't even yet a not-even-attempting-to-compile
test (probably the presence of socket() would be a good one for that).
Fairly detailed reports about headers and libraries would be helpful.
If the worst comes to the worst, stick #if 0...#endif around the code
in Src/Modules/zftp.c .


4482 (cdmatch2)and 4641 (${assoc[0]}) now applied; 4641 was supposed
to be there before.

nroff manual pages deleted, you now need yodl.

deleted modules-bltin by hand, which `make distclean' somehow missed.
Caused problems when building a statically linked shell.

Bart's scanmatchtable fix, 4674

Commented out vifirstnonblank() in vioperswapcase(), pending any
better patch for it.

Bart's viforwardword fix, 4678

My case-independent globbing fix (case-independent testing was broken
after a top level *), 4693

Sven's zle_tricky.c, 4697

Sven's patch to ignore completions if the cursor is not in a part to
be completed, 4698, plus addition, 4707

I have not added Sven's zerr() patch, 4699, in case it has side
effects, but I haven't heard anything on the subject and I haven't
looked at it.

Sven's pennockite heap memory patch, 4700

Sven's condition module patch, 4716, and addition, 4732, and the
function wrapper patch, 4734, and additions, 4742, 4769: the module.c
bits of these have been moved around a little to avoid clashes with
the AIXDYNAMIC stuff.  The wrapper stuff is still not finished, but
doesn't currently impinge on use of the shell.

Phil Pennock's patch to use associative arrays in stat, 4727

Unposted fix for use of printcompctlptr in completion widgets:
printcompctl() had acquired another argument.  (None of the mucking
around with completion widgets to fit in with the latest completion
code has been separately posted.)

My bash-like ${foo/orig/new} patch, 4736, and the version to do
shortest matching together with optimizations of all pattern matching
in variable strings, 4754.

Phil's patch for typeset -a docs, 4737

Nobody wanted my fix for `FOO=x eval external', so it's not there.

zftp, 4761

Bart's fix for conddef without dynamical modules, 4762

Bart's associative array patches for implentation of subscripting flags,
4763, plus fix 4766; typeset output 4764

Sven's completion listing fix, 4767

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

zerr() and errflag (Re: Latest patched development version)

[Bart Schaefer]

On Dec 14,  2:57pm, Peter Stephenson wrote:
} Subject: Latest patched development version
}
} I have not added Sven's zerr() patch, 4699, in case it has side
} effects, but I haven't heard anything on the subject and I haven't
} looked at it.

I've noticed a couple of other places in the code where zerr() is
called and then errflag is explicitly set.  This makes me think that
either (a) there is an undesired side effect, or (b) everybody else
who has noticed errflag bugs has been worried about (a) and therefore
fixed errflag in the caller.

Personally, I think it was a bad idea for zerr() to have the side-
effect of setting errflag in the first place.

In any case, if zerr() needs Sven's fix, then so does zerrnam() a few
lines later.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zerr() and errflag (Re: Latest patched development version)

[Peter Stephenson]

"Bart Schaefer" wrote:
> I've noticed a couple of other places in the code where zerr() is
> called and then errflag is explicitly set.  This makes me think that
> either (a) there is an undesired side effect, or (b) everybody else
> who has noticed errflag bugs has been worried about (a) and therefore
> fixed errflag in the caller.

Seems to be mainly in params.c, so it's possible it's just due to
someone once getting the wrong end of the stick.

> Personally, I think it was a bad idea for zerr() to have the side-
> effect of setting errflag in the first place.

Hence the distinction between zwarnnam() and zerrnam(), but there's no
zwarn(), mainly because it required too much new code and my seratonin
level wasn't high enough at the time, or something.  With the complete
set of four functions I think it's OK to have zerr() set errflag.  One
day I may get so fed up with potentials between adjoint sources in
SU(2) lattice gauge theory that I look at all the errflags.

> In any case, if zerr() needs Sven's fix, then so does zerrnam() a few
> lines later.

Maybe I just have to bite the bullet and try out both replacements.
It's too hard to tell what happens otherwise.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Latest patched development version

[Bruce Stephens]

Peter Stephenson <pws@ibmth.df.unipi.it> writes:

> I have put a new patched version of zsh 3.1.5 at
> 
> http://www.ifh.de/~pws/computing/zsh-3.1.5-pws-3.tar.gz

This fails to build for me on Solaris 2.5.1 with 

	./configure --enable-dynamic --prefix=/local

rm -f zsh
cc  -s  -o zsh main.o `cat stamp-modobjs`   -lsocket -ldl -lnsl -ltermcap -lc
Undefined                       first referenced
 symbol                             in file
wrappers                            exec.o
unload_module                       exec.o
ld: fatal: Symbol referencing errors. No output written to zsh
*** Error code 1

It fails for both SunPro C and egcs-1.1.1.  egcs also complains about
wrappers in init.c; I don't know why SunPro isn't complaining about
this file.

Re: Latest patched development version

[Peter Stephenson]

Bruce Stephens wrote:
> Undefined                       first referenced
>  symbol                             in file
> wrappers                            exec.o
> unload_module                       exec.o

It's the problem Bart was complaining about when you compile without
dynamic loading.  The following will fix this; I have updated
http://www.ifh.de/~pws/computing/zsh-3.1.5-pws-3.tar.gz
as well. (I have now successfully compiled this statically linked, so
after this you're on your own :-).)

The module.c chunk may well be my fault, since I moved Sven's bits
around to fit in with AIXDYNAMIC --- hence this chunk is not relevant
if you are building your own 3.1.5 patched version.  For the exec.c
part, Sven will have to decide eventually where the #ifdef DYNAMIC
should really go, but this does not currently affect use of the shell
at all so anyone trying to get this version to compile doesn't need to
worry about that.

*** Src/exec.c.wrap	Mon Dec 14 18:05:02 1998
--- Src/exec.c	Mon Dec 14 18:03:12 1998
***************
*** 2777,2786 ****
--- 2777,2788 ----
  	wrap->count--;
  	if (!wrap->count) {
  	    wrap->module->flags &= ~MOD_WRAPPER;
+ #ifdef DYNAMIC
  	    if (wrap->module->flags & MOD_UNLOAD) {
  		wrap->module->flags &= ~MOD_UNLOAD;
  		unload_module(wrap->module, NULL);
  	    }
+ #endif
  	}
  	if (!cont)
  	    return;
*** Src/module.c.wrap	Mon Dec 14 18:05:23 1998
--- Src/module.c	Mon Dec 14 18:04:27 1998
***************
*** 90,95 ****
--- 90,124 ----
      return hadf ? hads : 1;
  }
  
+ /* The list of function wrappers defined. */
+ 
+ /**/
+ FuncWrap wrappers;
+ 
+ /* This adds a definition for a wrapper. Return value is one in case of *
+  * error and zero if all went fine. */
+ 
+ /**/
+ int
+ addwrapper(Module m, FuncWrap w)
+ {
+     FuncWrap p, q;
+ 
+     if (w->flags & WRAPF_ADDED)
+ 	return 1;
+     for (p = wrappers, q = NULL; p; q = p, p = p->next);
+     if (q)
+ 	q->next = w;
+     else
+ 	wrappers = w;
+     w->next = NULL;
+     w->flags |= WRAPF_ADDED;
+     w->module = m;
+     w->count = 0;
+ 
+     return 0;
+ }
+ 
  #ifdef DYNAMIC
  
  /* $module_path ($MODULE_PATH) */
***************
*** 159,193 ****
  	b->flags &= ~BINF_ADDED;
      }
      return hadf ? hads : 1;
- }
-   
- /* The list of function wrappers defined. */
- 
- /**/
- FuncWrap wrappers;
- 
- /* This adds a definition for a wrapper. Return value is one in case of *
-  * error and zero if all went fine. */
- 
- /**/
- int
- addwrapper(Module m, FuncWrap w)
- {
-     FuncWrap p, q;
- 
-     if (w->flags & WRAPF_ADDED)
- 	return 1;
-     for (p = wrappers, q = NULL; p; q = p, p = p->next);
-     if (q)
- 	q->next = w;
-     else
- 	wrappers = w;
-     w->next = NULL;
-     w->flags |= WRAPF_ADDED;
-     w->module = m;
-     w->count = 0;
- 
-     return 0;
  }
  
  /* This removes the given wrapper definition from the list. Returned is *
--- 188,193 ----

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Latest patched development version

[Bruce Stephens]

Bruce Stephens <b.stephens@isode.com> writes:

> Peter Stephenson <pws@ibmth.df.unipi.it> writes:
> 
> > I have put a new patched version of zsh 3.1.5 at
> > 
> > http://www.ifh.de/~pws/computing/zsh-3.1.5-pws-3.tar.gz
> 
> This fails to build for me on Solaris 2.5.1 with 
> 
> 	./configure --enable-dynamic --prefix=/local

egcs-1.1.1 gives the following:

rm -f zsh
gcc  -s  -o zsh main.o `cat stamp-modobjs`   -lsocket -ldl -lnsl -ltermcap -lc
exec.o: In function `doshfunc':
exec.o(.text+0x59c0): undefined reference to `wrappers'
exec.o(.text+0x59e4): undefined reference to `wrappers'
exec.o(.text+0x5a14): undefined reference to `wrappers'
exec.o(.text+0x5a18): undefined reference to `wrappers'
exec.o: In function `runshfunc':
exec.o(.text+0x5c48): undefined reference to `unload_module'
init.o: In function `setupvals':
init.o(.text+0x10d4): undefined reference to `wrappers'
init.o(.text+0x10e0): undefined reference to `wrappers'
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `zsh'

Not that that helps greatly, I suspect.

Re: Latest patched development version

[Phil Pennock]

Erm, please ignore previous waffle post.  I should've read all the new
messages first.

Typing away merrily, Peter Stephenson produced the immortal words:
> I have put a new patched version of zsh 3.1.5 at
> 
> http://www.ifh.de/~pws/computing/zsh-3.1.5-pws-3.tar.gz

I don't suppose it's possible to provide bzip2 compressed forms too, is
it?  I know it's more space on the server, but:
 (a) bzip2 is patent-free and GPL so same distrib as gzip
 (b) It provides better compression.

I'm still waiting for it to download.  But as a comparison from
zsh-3.1.5 (using figure in announce post and from my own patched 3.1.4):
  zsh-3.1.5.tar.gz as announced,    size 867498 bytes.
  zsh-3.1.5.tar.bz2 made via patch, size 669971 bytes.

> Phil Pennock's patch to use associative arrays in stat, 4727

Could someone familiar with the depths of params.c please check the
sethparam function I added?  The post (4727 I guess) contained warnings
about the checks in that.  There are bound to be problems with the
unhandled cases.  Please?  I'm just feeling very nervous about it.
-- 
--> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++
E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+
G+ e+ h* r y?

Re: Latest patched development version

[Bart Schaefer]

On Dec 14,  6:54pm, Phil Pennock wrote:
} Subject: Re: Latest patched development version
}
} Could someone familiar with the depths of params.c please check the
} sethparam function I added?

I have a replacement for that sethparam() which I will be posting as
soon as I finish reconciling differences between pws-3 and my local
changes.  I was hoping to avoid the stat module, completion widgets,
and the ftp module for the time being, but it looks like they're too
much tangled in with other things.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Latest patched development version

[Sven Wischnowsky]

Bart Schaefer wrote:

> Is there any reason that -tc simply can't be implicit?  That is, why not
> always continue with the next suitable completion, leaving -t+ -t- and -tx
> to change what "next suitable" means?  And then perhaps throw in something
> like -tn to mean "no, DON'T continue."
> 
> Seems to me it's more often the case that you want to go on trying other
> possible completions rather than giving up.  The default should be what
> the most common case is.

(Even without getting more opinions on this I used some spare time to
build the patch below...)

After re-reading Bart's message I started to like the idea. So, the
patch below makes `-t' behave like Bart described above. The fact that 
the patch doesn't need to fiddle with zle_tricky.c shows that this
isn't that big a change in the concept of `-t'.
With this patch `-t' accepts only one character which says where to
continue to produce matches. Without any `-t' the next matching
compctl is used, since (as Bart already said) multiple matching
compctls weren't possible before (except for `-T') this shouldn't
introduce too much incompatibility. This also means that you don't
need `-tc' in `-T' or pattern compctls. On the other side, if you have 
a case where you don't want normal completion to be used, you should
add a `-tn' (so it's only a slight shift in incompatibilities to a
hopefully less common case).
Especially those who use `compctl -Tx 's[~]' -k friend ...' or
something like that to avoid the normal user-name generation should
put `-tn' in there or otherwise this will become pretty useless.

Any comments?

Bye
 Sven

diff -c os/Zle/compctl.c Src/Zle/compctl.c
*** os/Zle/compctl.c	Thu Jan 21 09:12:18 1999
--- Src/Zle/compctl.c	Thu Jan 21 10:12:04 1999
***************
*** 400,405 ****
--- 400,406 ----
      }
  
      memset((void *)&cct, 0, sizeof(cct));
+     cct.mask2 = CC_CCCONT;
  
      /* Loop through the flags until we have no more:        *
       * those with arguments are not properly allocated yet, *
***************
*** 516,541 ****
  			p = *++argv;
  			*argv = "" - 1;
  		    }
! 		    while (*p) {
! 			switch (*p) {
! 			case '+':
! 			    cct.mask2 |= CC_XORCONT;
! 			    break;
! 			case 'c':
! 			    cct.mask2 |= CC_CCCONT;
! 			    break;
! 			case '-':
! 			    cct.mask2 |= CC_PATCONT;
! 			    break;
! 			case 'x':
! 			    cct.mask2 |= CC_DEFCONT;
! 			    break;
! 			default:
! 			    zwarnnam(name, "invalid retry specification character `%c'",
! 				     NULL, *p);
! 			    return 1;
! 			}
! 			p++;
  		    }
  		}
  		break;
--- 517,544 ----
  			p = *++argv;
  			*argv = "" - 1;
  		    }
! 		    switch (*p) {
! 		    case '+':
! 			cct.mask2 = CC_XORCONT;
! 			break;
! 		    case 'n':
! 			cct.mask2 = 0;
! 			break;
! 		    case '-':
! 			cct.mask2 = CC_PATCONT;
! 			break;
! 		    case 'x':
! 			cct.mask2 = CC_DEFCONT;
! 			break;
! 		    default:
! 			zwarnnam(name, "invalid retry specification character `%c'",
! 				 NULL, *p);
! 			return 1;
! 		    }
! 		    if (p[1]) {
! 			zwarnnam(name, "too many retry specification characters: `%s'",
! 				 p + 1, 0);
! 			return 1;
  		    }
  		}
  		break;
***************
*** 835,840 ****
--- 838,844 ----
  		cc->xor = (Compctl) zcalloc(sizeof(*cc));
  		cc = cc->xor;
  		memset((void *)&cct, 0, sizeof(cct));
+ 		cct.mask2 = CC_CCCONT;
  	    }
  	}
      }
***************
*** 1362,1378 ****
  	    t >>= 1;
  	}
      }
!     if (flags2 & (CC_XORCONT | CC_CCCONT | CC_PATCONT | CC_DEFCONT)) {
  	printf(" -t");
  	if (flags2 & CC_XORCONT)
  	    putchar('+');
- 	if (flags2 & CC_CCCONT)
- 	    putchar('c');
  	if (flags2 & CC_PATCONT)
  	    putchar('-');
  	if (flags2 & CC_DEFCONT)
  	    putchar('x');
!     }
      /* now flags with arguments */
      printif(cc->mstr, 'M');
      if (flags2 & CC_NOSORT)
--- 1366,1381 ----
  	    t >>= 1;
  	}
      }
!     if (flags2 & (CC_XORCONT | CC_PATCONT | CC_DEFCONT)) {
  	printf(" -t");
  	if (flags2 & CC_XORCONT)
  	    putchar('+');
  	if (flags2 & CC_PATCONT)
  	    putchar('-');
  	if (flags2 & CC_DEFCONT)
  	    putchar('x');
!     } else if (!(flags2 & CC_CCCONT))
! 	printf(" -tn");
      /* now flags with arguments */
      printif(cc->mstr, 'M');
      if (flags2 & CC_NOSORT)
diff -c od/Zsh/compctl.yo Doc/Zsh/compctl.yo
*** od/Zsh/compctl.yo	Thu Jan 21 09:29:30 1999
--- Doc/Zsh/compctl.yo	Thu Jan 21 10:25:57 1999
***************
*** 85,91 ****
  to the user database is too slow and/or it contains too many users (so
  that completion after `tt(~)' is too slow to be usable), you can use
  
! nofill(tt(compctl -Tx  'C[0,*/*]' -f - 's[~]' -k friends -S/))
  
  to complete the strings in the array tt(friends) after a `tt(~)'.
  The first argument is necessary so that this form of ~-completion is
--- 85,91 ----
  to the user database is too slow and/or it contains too many users (so
  that completion after `tt(~)' is too slow to be usable), you can use
  
! nofill(tt(compctl -Tx  'C[0,*/*]' -f - 's[~]' -k friends -S/ -tn))
  
  to complete the strings in the array tt(friends) after a `tt(~)'.
  The first argument is necessary so that this form of ~-completion is
***************
*** 432,447 ****
  with the same name and the matches in those groups will not be mixed.
  )
  item(tt(-t) var(continue))(
! The var(continue)-string contains a set of characters that specify if 
! and when completion should continue to produce matches where it normally
! would not do that. The character tt(c) means that completion continues
! with the next suitable compctl (i.e. if you don't specify this in a
! tt(compctl -T), compctls for commands are never used). The character
! tt(PLUS()) is used to continue with the matches for the next alternative
! completion (see below). The characters tt(-) and tt(x) may be used in
! sub-lists for extended completion (see below). They will make the completion
! code use the flag list after the next tt(-) (if the corresponding pattern
! matches) and the default flag list (those before the tt(-x)), respectively.
  )
  item(tt(-M) var(match-spec))(
  This defines additional matching control specifications that should be used
--- 432,449 ----
  with the same name and the matches in those groups will not be mixed.
  )
  item(tt(-t) var(continue))(
! The var(continue)-string contains a character that specifies which set 
! of completion flags should be used next. Normally those of the next
! matching compctl are used, i.e. pattern compctls and normal compctls
! after tt(-T) and after a pattern compctl. If var(continue) is the
! character tt(PLUS()) the flags for the next alternative completion
! (see below) are used. The characters tt(-) and tt(x) can be used in
! sub-lists for extended completion (see below). They will make the
! completion code use the flag list after the next tt(-) (if the
! corresponding pattern matches) and the default flag list (those before
! the tt(-x)), respectively. if var(continue) is the character tt(n) no
! other flag lists are used, i.e. the generation of matches stops
! immediately.
  )
  item(tt(-M) var(match-spec))(
  This defines additional matching control specifications that should be used

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Latest patched development version

[Bart Schaefer]

On Jan 11, 11:05am, Sven Wischnowsky wrote:
} Subject: Re: Latest patched development version
}
} Bart Schaefer wrote:
} > Is there any reason that -tc simply can't be implicit?
} 
} I wanted to leave the previous behavior unchanged as much as
} possible. The `-T' is the only case where multiple compctl's were
} tested in all other cases making -t<whatever> implicit would make
} things differ from the way it was before my patches.

So that's the reason -tc *isn't* implicit, but nobody's yet said why
it *can't* or shouldn't be.

IMHO,

* There aren't very many cases of the previous behavior (other than -T)
  where another suitable completion would be found.
* Therefore, making -tc the default wouldn't affect anyone's existing
  completions very much, if at all.
* Even there were another suitable completion, the -tc behavior is
  probably the more desirable one.

} Anyway before I change anything I would like to hear a bit more what
} people would like to have, ok?

Of course.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Latest patched development version

[Sven Wischnowsky]

Bart Schaefer wrote:

> 
> A long time ago, in a year far far away, Sven Wischnowsky wrote:
> } Bruce Stephens wrote:
> } > Bruce Stephens <b.stephens@isode.com> writes:
> } > 
> } > > Completion seems to have vanished, but I just tried with zsh -f, and
> } > > it works again, so that's presumably just something that's changed
> } > > in the compctl syntax that's not being reported as an error.
> } > 
> } > I've found it.  It was this example completion:
> } > 
> } > compctl -Tx 's[/home/] C[0,^/home/*/*]'  -S '/' \
> } >     -s '$(niscat auto_home.org_dir | \
> } > 	awk '\''/export\/[a-zA-Z]*$/ {print $NF}'\'' FS=/)'
> } 
> } Peter's version contains my patch for completion continuing. With this 
> } we almost ever need a `-tc' in the `-T' completion.
> } 
> } (I said that trouble would come of that...)
> 
> Is there any reason that -tc simply can't be implicit?  That is, why not
> always continue with the next suitable completion, leaving -t+ -t- and -tx
> to change what "next suitable" means?  And then perhaps throw in something
> like -tn to mean "no, DON'T continue."
> 
> Seems to me it's more often the case that you want to go on trying other
> possible completions rather than giving up.  The default should be what
> the most common case is.

I wanted to leave the previous behavior unchanged as much as
possible. The `-T' is the only case where multiple compctl's were
tested in all other cases making -t<whatever> implicit would make
things differ from the way it was before my patches.
So we could make -tc implicit for -T (at least the `global' -tc,
before any -x). That would make things behave like they always did but 
I didn't like to add special cases at that time.
Anyway before I change anything I would like to hear a bit more what
people would like to have, ok?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Latest patched development version

[Bart Schaefer]

A long time ago, in a year far far away, Sven Wischnowsky wrote:
} Bruce Stephens wrote:
} > Bruce Stephens <b.stephens@isode.com> writes:
} > 
} > > Completion seems to have vanished, but I just tried with zsh -f, and
} > > it works again, so that's presumably just something that's changed
} > > in the compctl syntax that's not being reported as an error.
} > 
} > I've found it.  It was this example completion:
} > 
} > compctl -Tx 's[/home/] C[0,^/home/*/*]'  -S '/' \
} >     -s '$(niscat auto_home.org_dir | \
} > 	awk '\''/export\/[a-zA-Z]*$/ {print $NF}'\'' FS=/)'
} 
} Peter's version contains my patch for completion continuing. With this 
} we almost ever need a `-tc' in the `-T' completion.
} 
} (I said that trouble would come of that...)

Is there any reason that -tc simply can't be implicit?  That is, why not
always continue with the next suitable completion, leaving -t+ -t- and -tx
to change what "next suitable" means?  And then perhaps throw in something
like -tn to mean "no, DON'T continue."

Seems to me it's more often the case that you want to go on trying other
possible completions rather than giving up.  The default should be what
the most common case is.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Latest patched development version

[Sven Wischnowsky]

Bruce Stephens wrote:

> 
> Bruce Stephens <b.stephens@isode.com> writes:
> 
> > Completion seems to have vanished, but I just tried with zsh -f, and
> > it works again, so that's presumably just something that's changed
> > in the compctl syntax that's not being reported as an error.
> 
> I've found it.  It was this example completion:
> 
> # This is to complete all directories under /home, even those that are not
> # yet mounted (if you use the automounter).
> 
> # This is for NIS+ (e.g. Solaris 2.x)
> compctl -Tx 's[/home/] C[0,^/home/*/*]'  -S '/' -s '$(niscat auto_home.org_dir | \
> 	awk '\''/export\/[a-zA-Z]*$/ {print $NF}'\'' FS=/)'
> 
> Which doesn't work for me anyway (since directories are mounted
> differently), so I've just commented it out.  Things were working with
> previous versions of zsh, however, so this suggests that something has
> changed.

Peter's version contains my patch for completion continuing. With this 
we almost ever need a `-tc' in the `-T' completion.

(I said that trouble would come of that...)

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Latest patched development version

[Bruce Stephens]

Bruce Stephens <b.stephens@isode.com> writes:

> Completion seems to have vanished, but I just tried with zsh -f, and
> it works again, so that's presumably just something that's changed
> in the compctl syntax that's not being reported as an error.

I've found it.  It was this example completion:

# This is to complete all directories under /home, even those that are not
# yet mounted (if you use the automounter).

# This is for NIS+ (e.g. Solaris 2.x)
compctl -Tx 's[/home/] C[0,^/home/*/*]'  -S '/' -s '$(niscat auto_home.org_dir | \
	awk '\''/export\/[a-zA-Z]*$/ {print $NF}'\'' FS=/)'

Which doesn't work for me anyway (since directories are mounted
differently), so I've just commented it out.  Things were working with
previous versions of zsh, however, so this suggests that something has
changed.

Re: Latest patched development version

[Bruce Stephens]

Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> The changes in the configuration for AIXDYNAMIC (or whatever) have the
> effect that it now thinks it can't build dynamic loadable modules on
> Digital Unix 4.0. One problem is that the tests for load, unload,
> loadbind, and loadquery fail.

I get a "failed" for the underscore test:

	checking if your dlsym() needs a leading underscore... failed

on Solaris 2.5.1 with egcs-1.1.1.  But not with gcc-2.8.1, so possibly
this is some strange compiler problem.  config.log doesn't give
anything useful, so probably this isn't worth worrying about for the
moment.

zftp.c fails to compile:

/* bet there are machines which have neither INADDR_NONE nor in_addr_t. */

Lucky guess!  Solaris 2.5.1 seems to have s_addr as a u_long, so I
just replaced (in_addr_t) with (u_long), and it seems to work.  I
think, anyway.  I'm assuming this either catches the case when a
hostname can't be resolved (which I checked using a name that doesn't
exist), or when DNS server can't be contacted (which I haven't
checked).

Completion seems to have vanished, but I just tried with zsh -f, and
it works again, so that's presumably just something that's changed in
the compctl syntax that's not being reported as an error.

Re: Latest patched development version

[Peter Stephenson]

Sven Wischnowsky wrote:
> While fighting with this I also got an error in utils.c. In the
> function get_username() after the `#else' the variable current_uid is
> used but not defined.

The following is the only re-interpretation which makes sense to me.

*** Src/utils.c.uid	Tue Dec 15 09:59:21 1998
--- Src/utils.c	Tue Dec 15 13:35:46 1998
***************
*** 427,433 ****
  	    cached_username = ztrdup("");
      }
  #else /* !HAVE_GETPWUID */
!     cached_uid = current_uid;
  #endif /* !HAVE_GETPWUID */
      return cached_username;
  }
--- 427,433 ----
  	    cached_username = ztrdup("");
      }
  #else /* !HAVE_GETPWUID */
!     cached_uid = getuid();
  #endif /* !HAVE_GETPWUID */
      return cached_username;
  }

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Latest patched development version

[Sven Wischnowsky]

Hello

The changes in the configuration for AIXDYNAMIC (or whatever) have the
effect that it now thinks it can't build dynamic loadable modules on
Digital Unix 4.0. One problem is that the tests for load, unload,
loadbind, and loadquery fail.

I'm not in the mood to look any deeper into this now, maybe later...

While fighting with this I also got an error in utils.c. In the
function get_username() after the `#else' the variable current_uid is
used but not defined.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de