3.1.6 bug in NextStep/OpenStep 4.2

3.1.6 bug in NextStep/OpenStep 4.2

[Brian Boonstra]

Hey folks,

	Can anyone help me get 3.1.6 for OpenStep?  I'm now subscribed here,  
so replies to zsh-workers will be fine.  I've been attempting to compile  
from source.

	By finding the message

		http://www.zsh.org/mla/workers//1999/msg02372.html

in the archives, I managed to get zsh 3.1.6 to compile for OpenStep 4.2.  It  
is worth mentioning that I also had to mess with the Makefile, to the effect  
of specifying

		EXELDFLAGS      = -Wl,-x

for an install build -- I assume this is a flaw in autoconf.


	However, completion is not quite right.  In particular, if I run  
either the usual binary, I get completion with extra "2" characters, like  
this:

wo1203 % ls ../co                              /tmp/zsh/zsh-3.1.6/Src
Completion/   2  2config.guess* 2  2config.log    2  2configure*    2
Config/       2  2config.h      2  2config.status*2  2configure.in  2
config.cache  2  2config.h.in   2  2config.sub*   2  2              2



	I did get some warnings during compilation, notably the following three:

/bin/ld: warning /usr/lib/libtermcap.a(termcap.o) has external relocation  
entries in non-writable section (__TEXT,__text) for symbols:
__ctype_
_strcpy
_write
_close
_read
_open
_getenv
/bin/ld: warning /usr/lib/libtermcap.a(tgoto.o) has external relocation  
entries in non-writable section (__TEXT,__text) for symbols:
_strcpy
_strcat
/bin/ld: warning /usr/lib/libtermcap.a(tputs.o) has external relocation  
entries in non-writable section (__TEXT,__text) for symbols:
__ctype_



	I did attempt a debug build, but that dies with something like this:


wo1203 % gdb zsh                               /tmp/zsh/zsh-3.1.6/Src
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.14  (NEXTSTEP 4.0 --target i386), Copyright 1995 Free Software  
Foundation, Inc...
Reading symbols from /private/tmp/zsh/zsh-3.1.6/Src/zsh...done.

(gdb) r
Reading in symbols for crt0.c...done.
Dynamic Linkeditor at 0x12000000 offset 0x0
Executable at 0x2000 offset 0x0
/NextLibrary/Frameworks/System.framework/Versions/A/System at 0x5000000 offset 0x0
Reading symbols from loaded file...done.
wo1203 % Reading in symbols for zle_misc.c...done.p/zsh/zsh-3.1.6/Src
Program generated(1): Memory access exception on address 0x0 (protection failure).
0x81bbb in doinsert (str=0xbffff074 "l") at zle_misc.c:54
zle_misc.c:54: No such file or directory.
(gdb) quit




		Any suggestions?  I tried some of the Mac OS X erver and  
Darwin projects, since those are closely related to OpenStep 4.2, with  
similar bad luck.


			- Brian

Re: 3.1.6 bug in NextStep/OpenStep 4.2

[Sven Wischnowsky]

Brian Boonstra wrote:

> ...
>
> 	However, completion is not quite right.  In particular, if I run  
> either the usual binary, I get completion with extra "2" characters, like  
> this:
> 
> wo1203 % ls ../co                              /tmp/zsh/zsh-3.1.6/Src
> Completion/   2  2config.guess* 2  2config.log    2  2configure*    2
> Config/       2  2config.h      2  2config.status*2  2configure.in  2
> config.cache  2  2config.h.in   2  2config.sub*   2  2              2

I don't know about the other things, but I guess this is the same
problem mentioned by Brien Harvell (in 7443), only that he got `$<2>'
instead of the `2'.

To repeat: I think this is caused by the complist code. It prints the
termcap string for `%s' (standout off) at those places. What irritated 
me is that `print -P "%s"' didn't give him those `$<2>' strings.

I then suggested the patch in 7455 (which is appended below for your
convenience), but got no reply from him after that, so I don't know if 
it fixes the problem (I guess not).

Otherwise, I can only suspect a broken term{cap,info} entry, but then
you would have noticed that before, I think.

So it boils down to: I don't really know where the problem is but I'd
really like to fix it. Anyone have any ideas about this?

Bye
 Sven

diff -u os/Zle/complist.c Src/Zle/complist.c
--- os/Zle/complist.c	Thu Aug 19 16:00:04 1999
+++ Src/Zle/complist.c	Fri Aug 20 10:14:29 1999
@@ -194,13 +194,17 @@
     }
 }
 
+/* Combined length of LC and RC, maximum length of capability strings. */
+
+static int lr_caplen, max_caplen;
+
 /* This initializes the given terminal color structure. */
 
 static void
 getcols(Listcols c)
 {
     char *s;
-    int i;
+    int i, l;
 
     if (!(s = getsparam("ZLS_COLORS")) &&
 	!(s = getsparam("ZLS_COLOURS"))) {
@@ -222,9 +226,15 @@
 	s = getcoldef(c, s);
 
     /* Use default values for those that aren't set explicitly. */
-    for (i = 0; i < NUM_COLS; i++)
+    max_caplen = lr_caplen = 0;
+    for (i = 0; i < NUM_COLS; i++) {
 	if (!c->cols[i])
 	    c->cols[i] = defcols[i];
+	if ((l = (c->cols[i] ? strlen(c->cols[i]) : 0)) > max_caplen)
+	    max_caplen = l;
+    }
+    lr_caplen = strlen(c->cols[COL_LC]) + strlen(c->cols[COL_RC]);
+
     /* Default for missing files. */
     if (!c->cols[COL_MI])
 	c->cols[COL_MI] = c->cols[COL_FI];
@@ -235,14 +245,24 @@
 static int last_col = COL_NO;
 
 static void
+zlrputs(Listcols c, char *cap)
+{
+    VARARR(char, buf, lr_caplen + max_caplen + 1);
+
+    strcpy(buf, c->cols[COL_LC]);
+    strcat(buf, cap);
+    strcat(buf, c->cols[COL_RC]);
+
+    tputs(buf, 1, putshout);
+}
+
+static void
 zcputs(Listcols c, int colour)
 {
     if (colour != last_col
 	&& (last_col < COL_NO
 	    || strcmp(c->cols[last_col], c->cols[colour]))) {
-	fputs(c->cols[COL_LC], shout);
-	fputs(c->cols[colour], shout);
-	fputs(c->cols[COL_RC], shout);
+	zlrputs(c, c->cols[colour]);
 	last_col = colour;
     }
     return;
@@ -260,11 +280,9 @@
     for (e = c->exts; e; e = e->next)
 	if (strsfx(e->ext, n)) {	/* XXX: unoptimised if used */
 	    if (last_col < COL_NO
-		|| strcmp(c->cols[last_col], e->col)) {
-		fputs(c->cols[COL_LC], shout);
-		fputs(e->col, shout);
-		fputs(c->cols[COL_RC], shout);
-	    }
+		|| strcmp(c->cols[last_col], e->col))
+		zlrputs(c, e->col);
+
 	    last_col = COL_NO - 1;
 	    return;
 	}
@@ -565,7 +583,7 @@
 			while (a--)
 			    putc(' ', shout);
 			if (col.cols[COL_EC])
-			    fputs(col.cols[COL_EC], shout);
+			    tputs(col.cols[COL_EC], 1, putshout);
 			else
 			    zcputs(&col, COL_NO);
 			break;
@@ -614,14 +632,14 @@
 		    while (a--)
 			putc(' ', shout);
 		    if (col.cols[COL_EC])
-			fputs(col.cols[COL_EC], shout);
+			tputs(col.cols[COL_EC], 1, putshout);
 		    else
 			zcputs(&col, COL_NO);
 		    if (i) {
 			zcputs(&col, COL_NO);
 			fputs("  ", shout);
 			if (col.cols[COL_EC])
-			    fputs(col.cols[COL_EC], shout);
+			    tputs(col.cols[COL_EC], 1, putshout);
 			else
 			    zcputs(&col, COL_NO);
 		    }
@@ -636,7 +654,7 @@
 		    while (a--)
 			putc(' ', shout);
 		    if (col.cols[COL_EC])
-			fputs(col.cols[COL_EC], shout);
+			tputs(col.cols[COL_EC], 1, putshout);
 		    else
 			zcputs(&col, COL_NO);
 		}

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

Re: 3.1.6 bug in NextStep/OpenStep 4.2

[Brian Boonstra]

Hi Sven (and all)

	I applied the patch (in 7513 and 7455) and it fixed the problem  
perfectly!  Similarly to what Brian H. saw, `print -P "%s"' was not giving me  
any extraneous characters.

	For the benefit of those joining late, in order to get zsh 3.1.6 to  
compile on OpenStep, you also need the patch from 2372.

	BTW, Sven, this is especially welcome on OpenStep/NextStep, because  
the Terminal application supplied by them is so darn good that few people  
ever use anything else.  And it does only vt100.


		Thanks,


			Brian



Sven Wischnowsky wrote:
> Brian Boonstra wrote:
> > However, completion is not quite right.  In particular, if I run
> > either the usual binary, I get completion with extra "2" characters, like
> > this:
> I don't know about the other things, but I guess this is the same
> problem mentioned by Brien Harvell (in 7443), only that he got `$<2>'
> instead of the `2'.
>
> To repeat: I think this is caused by the complist code. It prints the
> termcap string for `%s' (standout off) at those places. What irritated
> me is that `print -P "%s"' didn't give him those `$<2>' strings.
>
> I then suggested the patch in 7455 (which is appended below for your
> convenience), but got no reply from him after that, so I don't know if
> it fixes the problem (I guess not).