termcap bug on Linux

termcap bug on Linux

[Andrej Borsenkow]

Mandrake cooker (currently glibc-2.2.3, termcap-11.0.1-4mdk) compiled 
with termcap, no ncurses.tgetflag() returns 0 for both unset and 
nonexsiting flags, which means that $termcap[cap] returns "no" for 
almost everything except numeric capabilities. As example:

bor@localhost% print $termcap[ae]
no

even when `ae' is string capability and is defined.

The only possible solution seems to check for string first; at least 
then existing string caps will be returned correctly.

-andrej

Re: termcap bug on Linux

[Bart Schaefer]

On May 27,  5:09pm, Andrej Borsenkow wrote:
} Subject: termcap bug on Linux
}
} Mandrake cooker (currently glibc-2.2.3, termcap-11.0.1-4mdk) compiled 
} with termcap, no ncurses.  tgetflag() returns 0 for both unset and 
} nonexsiting flags, which means that $termcap[cap] returns "no" for 
} almost everything except numeric capabilities.

Does the following patch help?  This duplicates code from echotc() into
gettermcap() -- so the two should at least now agree with each other,
which they might not have before, even if they're both wrong.

Does something similar need to go into scantermcap() ?

(There are a bunch of extra hunks that just delete whitespace, sorry.)

Common subdirectories: zsh-forge/current/Src/Modules/CVS and zsh-4.0/Src/Modules/CVS
diff -u zsh-forge/current/Src/Modules/termcap.c zsh-4.0/Src/Modules/termcap.c
--- zsh-forge/current/Src/Modules/termcap.c	Thu Apr 26 09:08:03 2001
+++ zsh-4.0/Src/Modules/termcap.c	Mon May 28 15:21:21 2001
@@ -109,7 +109,7 @@
     /* get a string-type capability */
     u = buf;
     t = tgetstr(s, &u);
-    if (!t || !*t) {
+    if (t == (char *)-1 || !t || !*t) {
 	/* capability doesn't exist, or (if boolean) is off */
 	zwarnnam(name, "no such capability: %s", s, 0);
 	return 1;
@@ -225,15 +225,34 @@
     pm->level = 0;
     u = buf;
 
+    /* logic in the following cascade copied from echotc, above */
+
     if ((num = tgetnum(name)) != -1) {
 	pm->u.val = num;
 	pm->flags |= PM_INTEGER;
+	return (HashNode) pm;
+    }
+#if !defined(NCURSES_VERSION) || !defined(COLOR_PAIR)
+    if ((num = tgetflag(name)) > 0) {
+	pm->u.str = dupstring("yes");
+	pm->flags |= PM_SCALAR;
+	return (HashNode) pm;
     }
-    else if ((num = tgetflag(name)) != -1) {
-	pm->u.str = num ? dupstring("yes") : dupstring("no");
+#else /* NCURSES_VERSION && COLOR_PAIR */
+    switch (tgetflag(name)) {
+    case -1:
+	break;
+    case 0:
+	pm->u.str = dupstring("no");
+	pm->flags |= PM_SCALAR;
+	return (HashNode) pm;
+    default:
+	pm->u.str = dupstring("yes");
 	pm->flags |= PM_SCALAR;
+	return (HashNode) pm;
     }
-    else if ((tcstr = (char *)tgetstr(name,&u)) != NULL && tcstr != (char *)-1)
+#endif /* NCURSES_VERSION && COLOR_PAIR */
+    if ((tcstr = tgetstr(name, &u)) != NULL && tcstr != (char *)-1)
     {
 	pm->u.str = dupstring(tcstr);
 	pm->flags |= PM_SCALAR;
@@ -262,7 +281,7 @@
 	"mi", "ms", "nx", "xb", "NP", "ND", "NR", "os", "5i", "YD", "YE",
 	"es", "hz", "ul", "xo", NULL};
 #endif
-    
+
 #ifndef HAVE_NUMCODES
     static char *numcodes[] = {
 	"co", "it", "lh", "lw", "li", "lm", "sg", "ma", "Co", "pa", "MW",
@@ -322,7 +341,7 @@
     pm->ename = NULL;
     pm->old = NULL;
     u = buf;
-    
+
     pm->flags = PM_READONLY | PM_SCALAR;
     for (capcode = (char **)boolcodes; *capcode; capcode++) {
 	if ((num = tgetflag(*capcode)) != -1) {
@@ -331,7 +350,7 @@
 	    func((HashNode) pm, flags);
 	}
     }
-    
+
     pm->flags = PM_READONLY | PM_INTEGER;
     for (capcode = (char **)numcodes; *capcode; capcode++) {
 	if ((num = tgetnum(*capcode)) != -1) {
@@ -340,7 +359,7 @@
 	    func((HashNode) pm, flags);
 	}
     }
-    
+
     pm->flags = PM_READONLY | PM_SCALAR;
     for (capcode = (char **)strcodes; *capcode; capcode++) {
 	if ((tcstr = (char *)tgetstr(*capcode,&u)) != NULL &&

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

Re: termcap bug on Linux

[Bart Schaefer]

On May 28, 10:25pm, Bart Schaefer wrote:
}
} Does the following patch help?
} 
} Does something similar need to go into scantermcap() ?

Should I commit the patch?

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

Re: termcap bug on Linux

[Clint Adams]

> Should I commit the patch?

The message I was thinking of is 13987.  Maybe checking to see if
NCURSES_VERSION is defined and less than 5 is sufficient.

RE: termcap bug on Linux

[Andrej Borsenkow]

>
> On May 28, 10:25pm, Bart Schaefer wrote:
> }
> } Does the following patch help?
> }
> } Does something similar need to go into scantermcap() ?
>
> Should I commit the patch?
>

Yes. About scantermcap - I am not sure. Currently it returns "no" for both
unexisting and unset flags; if we change this as well, it will return
nothing for unexisting flags. I am not  sure how useful $termcap is at all,
given that there is no way to associate returned values with capabilities.
Two possible valid usages are ${(k)termcap} or ${(kv)termcap}. For
consistency, I'd suggest to change scantermcap as well but I do not
insist.Clint?

-andrej

Re: termcap bug on Linux

[Bart Schaefer]

On May 30, 10:24am, Andrej Borsenkow wrote:
}
} > On May 28, 10:25pm, Bart Schaefer wrote:
} >
} > Should I commit the patch?
} 
} Yes.

OK, but sourceforge seems to be either inaccessible or at a painful crawl
just now, so I'm not going ot get to it for at least several hours.

} About scantermcap - I am not sure. Currently it returns "no" for both
} unexisting and unset flags; if we change this as well, it will return
} nothing for unexisting flags.

I'd say we do need to change it, then ... scantermcap() should produce
the same results as doing $termcap[$cap] for every possible $cap.

} I am not sure how useful $termcap is at all, given that there is no
} way to associate returned values with capabilities.

I don't think I understand what you mean.  Do you mean, there's no way
to tell whether a returned value should be interpreted as a boolean, a
number, or a string?  That is a shortcoming, it's true.

Parameterized capabilities like "move N columns left" really require
`echotc' to insert the N in the right place, too.

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

RE: termcap bug on Linux

[Andrej Borsenkow]

>
> } I am not sure how useful $termcap is at all, given that there is no
> } way to associate returned values with capabilities.
>
> I don't think I understand what you mean.

I mean ${termcap} as opposed to ${termcap[some-cap]}. Plain $termcap returns
array of values but you have no (easy) way to associate them with
capabilities. OTOH ${(kv)termcap} could be used to scan all available
values. That was what I meant.

-andrej

Re: termcap bug on Linux

[Clint Adams]

> Yes. About scantermcap - I am not sure. Currently it returns "no" for both
> unexisting and unset flags; if we change this as well, it will return
> nothing for unexisting flags. I am not  sure how useful $termcap is at all,
> given that there is no way to associate returned values with capabilities.
> Two possible valid usages are ${(k)termcap} or ${(kv)termcap}. For
> consistency, I'd suggest to change scantermcap as well but I do not
> insist.Clint?

I'm fine with the consistency.  I just think that an unconditional
reliance on NCURSES_VERSION being set is going to lead to trouble.

Re: termcap bug on Linux

[Bart Schaefer]

On May 30, 10:00am, Clint Adams wrote:
} Subject: Re: termcap bug on Linux
}
} I'm fine with the consistency.  I just think that an unconditional
} reliance on NCURSES_VERSION being set is going to lead to trouble.

Back in 13987 you wrote:
} ncurses 4.2's tgetflag() will return ERR (-1) if called with an
} argument not found in boolcodes. ncurses 5.2's tgetflag() will return
} 0, a la Solaris.

The test in termcap.c is

    #if !defined(NCURSES_VERSION) || !defined(COLOR_PAIR)

COLOR_PAIR is defined in ncurses 4.2, so apparently this behavior has
bounced back and forth with different versions of ncurses.  So it looks
as if a configure test may be the safest approach, but it might be OK
to test (NCURSES_MAJOR_VERSION < 5).

I'm going to commit 14516 as it is, and then look at this a bit more.

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

PATCH (again) Re: termcap bug on Linux

[Bart Schaefer]

I wrote earlier:
}
} I'm going to commit 14516 as it is, and then look at this a bit more.

OK, here's a patch for consideration.  This factors out the tgetflag()
stuff into a new function ztgetflag(), which believes tgetflag() only
when it returns -1 [no such cap] or != 0 ["yes"].  Otherwise it searches
the boolcodes for the cap name and returns 0 ["no"] only if it finds
the name there; the fallback is to return -1.

The end result is that this consistently treats "known" flag cap names
as either true or false, even if they don't actually appear in the term
definition, and will consistently treat "unknown" cap names as "no such
capability".  An "unknown" cap that is set to true is still at the mercy
of tgetflag(), but I don't see any way to work around that at all -- and
we do want to yield true for any previously-unknown capability that may
come along and be set.

"Consistently" here means on a particular installation -- it might be
that zsh on an ncurses 4.2 system does not agree with zsh on an ncurses
5.2 system even given identical term defs.

If we don't want to trust the -1 return from tgetflag() at all, ever,
just remove the `break' from the -1 case in ztgetflag().

diff -u zsh-forge/current/Src/Modules/termcap.c zsh-4.0/Src/Modules/termcap.c
--- zsh-forge/current/Src/Modules/termcap.c	Wed May 30 08:30:41 2001
+++ zsh-4.0/Src/Modules/termcap.c	Wed May 30 10:47:34 2001
@@ -67,6 +67,38 @@
 
 static Param termcap_pm;
 
+#ifndef HAVE_BOOLCODES
+static char *boolcodes[] = {
+    "bw", "am", "ut", "cc", "xs", "YA", "YF", "YB", "xt", "xn", "eo",
+    "gn", "hc", "HC", "km", "YC", "hs", "hl", "in", "YG", "da", "db",
+    "mi", "ms", "nx", "xb", "NP", "ND", "NR", "os", "5i", "YD", "YE",
+    "es", "hz", "ul", "xo", NULL};
+#endif
+
+/**/
+static int
+ztgetflag(char *s)
+{
+    char **b;
+
+    /* ncurses can tell if an existing boolean capability is *
+     * off, but other curses variants can't, so we fudge it. *
+     * This feature of ncurses appears to have gone away as  *
+     * of NCURSES_MAJOR_VERSION == 5, so don't rely on it.   */
+    switch (tgetflag(s)) {
+    case -1:
+	break;
+    case 0:
+	for (b = (char **)boolcodes; *b; ++b)
+	    if (s[0] == (*b)[0] && s[1] == (*b)[1])
+		return 0;
+	break;
+    default:
+	return 1;
+    }
+    return -1;
+}
+
 /* echotc: output a termcap */
 
 /**/
@@ -86,16 +118,8 @@
 	printf("%d\n", num);
 	return 0;
     }
-    /* if the specified termcap is boolean, and set, say so  *
-     * ncurses can tell if an existing boolean capability is *
-     * off so in this case we print "no".                    */
-#if !defined(NCURSES_VERSION) || !defined(COLOR_PAIR)
-    if (tgetflag(s) > 0) {
-	puts("yes");
-	return (0);
-    }
-#else /* NCURSES_VERSION && COLOR_PAIR */
-    switch (tgetflag(s)) {
+    /* if the specified termcap is boolean, and set, say so  */
+    switch (ztgetflag(s)) {
     case -1:
 	break;
     case 0:
@@ -105,7 +129,6 @@
 	puts("yes");
 	return 0;
     }
-#endif /* NCURSES_VERSION && COLOR_PAIR */
     /* get a string-type capability */
     u = buf;
     t = tgetstr(s, &u);
@@ -232,14 +255,7 @@
 	pm->flags |= PM_INTEGER;
 	return (HashNode) pm;
     }
-#if !defined(NCURSES_VERSION) || !defined(COLOR_PAIR)
-    if ((num = tgetflag(name)) > 0) {
-	pm->u.str = dupstring("yes");
-	pm->flags |= PM_SCALAR;
-	return (HashNode) pm;
-    }
-#else /* NCURSES_VERSION && COLOR_PAIR */
-    switch (tgetflag(name)) {
+    switch (ztgetflag(name)) {
     case -1:
 	break;
     case 0:
@@ -251,7 +267,6 @@
 	pm->flags |= PM_SCALAR;
 	return (HashNode) pm;
     }
-#endif /* NCURSES_VERSION && COLOR_PAIR */
     if ((tcstr = tgetstr(name, &u)) != NULL && tcstr != (char *)-1)
     {
 	pm->u.str = dupstring(tcstr);
@@ -274,14 +289,6 @@
     int num;
     char **capcode, *tcstr, buf[2048], *u;
 
-#ifndef HAVE_BOOLCODES
-    static char *boolcodes[] = {
-	"bw", "am", "ut", "cc", "xs", "YA", "YF", "YB", "xt", "xn", "eo",
-	"gn", "hc", "HC", "km", "YC", "hs", "hl", "in", "YG", "da", "db",
-	"mi", "ms", "nx", "xb", "NP", "ND", "NR", "os", "5i", "YD", "YE",
-	"es", "hz", "ul", "xo", NULL};
-#endif
-
 #ifndef HAVE_NUMCODES
     static char *numcodes[] = {
 	"co", "it", "lh", "lw", "li", "lm", "sg", "ma", "Co", "pa", "MW",
@@ -344,7 +351,7 @@
 
     pm->flags = PM_READONLY | PM_SCALAR;
     for (capcode = (char **)boolcodes; *capcode; capcode++) {
-	if ((num = tgetflag(*capcode)) != -1) {
+	if ((num = ztgetflag(*capcode)) != -1) {
 	    pm->u.str = num ? dupstring("yes") : dupstring("no");
 	    pm->nam = dupstring(*capcode);
 	    func((HashNode) pm, flags);

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

Re: termcap bug on Linux

[Andrej Borsenkow]

Bart Schaefer wrote:

> On May 27,  5:09pm, Andrej Borsenkow wrote:
> } Subject: termcap bug on Linux
> }
> } Mandrake cooker (currently glibc-2.2.3, termcap-11.0.1-4mdk) compiled 
> } with termcap, no ncurses.  tgetflag() returns 0 for both unset and 
> } nonexsiting flags, which means that $termcap[cap] returns "no" for 
> } almost everything except numeric capabilities.
> 
> Does the following patch help?  This duplicates code from echotc() into
> gettermcap() -- so the two should at least now agree with each other,
> which they might not have before, even if they're both wrong.
> 


Yes.


> Does something similar need to go into scantermcap() ?
>


I guess, no. In scantermcap() we know type of each capability.

-andrej 

Re: termcap bug on Linux

[Clint Adams]

> Yes.

I don't know if I ever received 13988, but I don't think I ever read it.

AB> In such cases I always ask myself - what happens, if a program is linked
AB> against dynamic library? Is it possible to silently exchange 4.2 version
AB> against 5.2 version? That would definitely break a lot of things.

On a sane system the soname should reflect the major number.  So
zsh linked against /usr/lib/libncurses.so.5 would not run on
a system with only /usr/lib/libncurses.so.4.

Re: termcap bug on Linux

[Clint Adams]

> +#if !defined(NCURSES_VERSION) || !defined(COLOR_PAIR)

I faintly remember there being a problem here since ncurses
4 behaves one way and ncurses 5 another.  I may have posted
something to the list to that effect, though I don't remember
the details.