zsh-workers
 help / color / mirror / code / Atom feed
* Re: 3.1.6 bug in NextStep/OpenStep 4.2
@ 1999-08-27  7:13 Sven Wischnowsky
  1999-08-27 14:27 ` Brian Boonstra
  0 siblings, 1 reply; 5+ messages in thread
From: Sven Wischnowsky @ 1999-08-27  7:13 UTC (permalink / raw)
  To: zsh-workers


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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 3.1.6 bug in NextStep/OpenStep 4.2
  1999-08-27  7:13 3.1.6 bug in NextStep/OpenStep 4.2 Sven Wischnowsky
@ 1999-08-27 14:27 ` Brian Boonstra
  1999-08-27 19:37   ` NEW BUG: " Brian Boonstra
  0 siblings, 1 reply; 5+ messages in thread
From: Brian Boonstra @ 1999-08-27 14:27 UTC (permalink / raw)
  To: zsh-workers; +Cc: luomat

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).


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: NEW BUG: 3.1.6 bug in NextStep/OpenStep 4.2
  1999-08-27 14:27 ` Brian Boonstra
@ 1999-08-27 19:37   ` Brian Boonstra
  1999-08-27 19:48     ` Brian Boonstra
  0 siblings, 1 reply; 5+ messages in thread
From: Brian Boonstra @ 1999-08-27 19:37 UTC (permalink / raw)
  To: zsh-workers

Hi Folks

	Well, I have a compilation that runs, and completion works well.   
But now I notice that the terminal hangs after I perform any kind of command  
except shell builtins.  For example, "ls", "df", and "finger" all hang after  
their output, whereas "echo" and "alias" do not hang.

	Note that this has nothing to do with the patch Sven supplied to fix  
complist.c.  I have applied one other set of patches, though, namely the  
ones found here:

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


	I doubt they are at fault, since they only patch the necessary (for  
me) third argument onto fcntl in utils.c and init.c.


	I tried compiling a debug version, but that version always gives a  
Bus Error on the first keystroke, so I'm afraid I can't be more specific.   
Anybody have ideas?



		Regards,


				Brian



Brian Boonstra wrote:
> 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.
>
> ...
>
> Sven Wischnowsky wrote:
> > Brian Boonstra wrote:
> > 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).


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: NEW BUG: 3.1.6 bug in NextStep/OpenStep 4.2
  1999-08-27 19:37   ` NEW BUG: " Brian Boonstra
@ 1999-08-27 19:48     ` Brian Boonstra
  0 siblings, 0 replies; 5+ messages in thread
From: Brian Boonstra @ 1999-08-27 19:48 UTC (permalink / raw)
  To: zsh-workers

Hi

> Note that this has nothing to do with the patch Sven supplied to fix
> complist.c


	I forgot to mention that the reason I know this is that I purposely  
compiled a version without Sven's patch.  The completion bug was back (as  
expected) and the hanging bug was there as well.




			- Brian 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* 3.1.6 bug in NextStep/OpenStep 4.2
@ 1999-08-26 18:56 Brian Boonstra
  0 siblings, 0 replies; 5+ messages in thread
From: Brian Boonstra @ 1999-08-26 18:56 UTC (permalink / raw)
  To: zsh-workers

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~1999-08-27 19:49 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-08-27  7:13 3.1.6 bug in NextStep/OpenStep 4.2 Sven Wischnowsky
1999-08-27 14:27 ` Brian Boonstra
1999-08-27 19:37   ` NEW BUG: " Brian Boonstra
1999-08-27 19:48     ` Brian Boonstra
  -- strict thread matches above, loose matches on Subject: below --
1999-08-26 18:56 Brian Boonstra

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).