* termcap bug on Linux @ 2001-05-27 13:09 Andrej Borsenkow 2001-05-28 22:25 ` Bart Schaefer 0 siblings, 1 reply; 13+ messages in thread From: Andrej Borsenkow @ 2001-05-27 13:09 UTC (permalink / raw) To: ZSH Workers Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: termcap bug on Linux 2001-05-27 13:09 termcap bug on Linux Andrej Borsenkow @ 2001-05-28 22:25 ` Bart Schaefer 2001-05-29 16:05 ` Bart Schaefer ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Bart Schaefer @ 2001-05-28 22:25 UTC (permalink / raw) To: Andrej Borsenkow, ZSH Workers Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: termcap bug on Linux 2001-05-28 22:25 ` Bart Schaefer @ 2001-05-29 16:05 ` Bart Schaefer 2001-05-29 18:56 ` Clint Adams 2001-05-30 6:24 ` Andrej Borsenkow 2001-05-29 18:06 ` Andrej Borsenkow 2001-05-29 18:48 ` Clint Adams 2 siblings, 2 replies; 13+ messages in thread From: Bart Schaefer @ 2001-05-29 16:05 UTC (permalink / raw) To: ZSH Workers Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: termcap bug on Linux 2001-05-29 16:05 ` Bart Schaefer @ 2001-05-29 18:56 ` Clint Adams 2001-05-30 6:24 ` Andrej Borsenkow 1 sibling, 0 replies; 13+ messages in thread From: Clint Adams @ 2001-05-29 18:56 UTC (permalink / raw) To: Bart Schaefer; +Cc: ZSH Workers Mailing List > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: termcap bug on Linux 2001-05-29 16:05 ` Bart Schaefer 2001-05-29 18:56 ` Clint Adams @ 2001-05-30 6:24 ` Andrej Borsenkow 2001-05-30 7:41 ` Bart Schaefer 2001-05-30 14:00 ` Clint Adams 1 sibling, 2 replies; 13+ messages in thread From: Andrej Borsenkow @ 2001-05-30 6:24 UTC (permalink / raw) To: ZSH Workers Mailing List > > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: termcap bug on Linux 2001-05-30 6:24 ` Andrej Borsenkow @ 2001-05-30 7:41 ` Bart Schaefer 2001-05-30 8:03 ` Andrej Borsenkow 2001-05-30 14:00 ` Clint Adams 1 sibling, 1 reply; 13+ messages in thread From: Bart Schaefer @ 2001-05-30 7:41 UTC (permalink / raw) To: ZSH Workers Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: termcap bug on Linux 2001-05-30 7:41 ` Bart Schaefer @ 2001-05-30 8:03 ` Andrej Borsenkow 0 siblings, 0 replies; 13+ messages in thread From: Andrej Borsenkow @ 2001-05-30 8:03 UTC (permalink / raw) To: ZSH Workers Mailing List > > } 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: termcap bug on Linux 2001-05-30 6:24 ` Andrej Borsenkow 2001-05-30 7:41 ` Bart Schaefer @ 2001-05-30 14:00 ` Clint Adams 2001-05-30 15:29 ` Bart Schaefer 1 sibling, 1 reply; 13+ messages in thread From: Clint Adams @ 2001-05-30 14:00 UTC (permalink / raw) To: Andrej Borsenkow; +Cc: ZSH Workers Mailing List > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: termcap bug on Linux 2001-05-30 14:00 ` Clint Adams @ 2001-05-30 15:29 ` Bart Schaefer 2001-05-30 19:54 ` PATCH (again) " Bart Schaefer 0 siblings, 1 reply; 13+ messages in thread From: Bart Schaefer @ 2001-05-30 15:29 UTC (permalink / raw) To: ZSH Workers Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* PATCH (again) Re: termcap bug on Linux 2001-05-30 15:29 ` Bart Schaefer @ 2001-05-30 19:54 ` Bart Schaefer 0 siblings, 0 replies; 13+ messages in thread From: Bart Schaefer @ 2001-05-30 19:54 UTC (permalink / raw) To: ZSH Workers Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: termcap bug on Linux 2001-05-28 22:25 ` Bart Schaefer 2001-05-29 16:05 ` Bart Schaefer @ 2001-05-29 18:06 ` Andrej Borsenkow 2001-05-29 20:12 ` Clint Adams 2001-05-29 18:48 ` Clint Adams 2 siblings, 1 reply; 13+ messages in thread From: Andrej Borsenkow @ 2001-05-29 18:06 UTC (permalink / raw) To: Bart Schaefer, ZSH Workers Mailing List 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: termcap bug on Linux 2001-05-29 18:06 ` Andrej Borsenkow @ 2001-05-29 20:12 ` Clint Adams 0 siblings, 0 replies; 13+ messages in thread From: Clint Adams @ 2001-05-29 20:12 UTC (permalink / raw) To: Andrej Borsenkow; +Cc: Bart Schaefer, ZSH Workers Mailing List > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: termcap bug on Linux 2001-05-28 22:25 ` Bart Schaefer 2001-05-29 16:05 ` Bart Schaefer 2001-05-29 18:06 ` Andrej Borsenkow @ 2001-05-29 18:48 ` Clint Adams 2 siblings, 0 replies; 13+ messages in thread From: Clint Adams @ 2001-05-29 18:48 UTC (permalink / raw) To: Bart Schaefer; +Cc: Andrej Borsenkow, ZSH Workers Mailing List > +#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. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2001-05-30 19:55 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-05-27 13:09 termcap bug on Linux Andrej Borsenkow 2001-05-28 22:25 ` Bart Schaefer 2001-05-29 16:05 ` Bart Schaefer 2001-05-29 18:56 ` Clint Adams 2001-05-30 6:24 ` Andrej Borsenkow 2001-05-30 7:41 ` Bart Schaefer 2001-05-30 8:03 ` Andrej Borsenkow 2001-05-30 14:00 ` Clint Adams 2001-05-30 15:29 ` Bart Schaefer 2001-05-30 19:54 ` PATCH (again) " Bart Schaefer 2001-05-29 18:06 ` Andrej Borsenkow 2001-05-29 20:12 ` Clint Adams 2001-05-29 18:48 ` Clint Adams
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).