Summary:ASTERISK-02456: [patch] Detect terminals which support color
Reporter:Tilghman Lesher (tilghman)Labels:
Date Opened:2004-09-24 01:44:47Date Closed:2008-01-15 15:08:34.000-0600
Versions:Frequency of
Environment:Attachments:( 0) 20040928__detect_terminals_with_color.diff.txt
Description:term.c currently hardcodes a number of terminal names which support colors, as the basis for the vt100compat setting.  While this worked, it doesn't scale, in that everytime somebody finds another terminal that supports color, they have to add it into the code, for color to work.

The alternative (this patch) is to read the corresponding terminfo file to determine whether a particular terminal supports color.
Comments:By: Mark Spencer (markster) 2004-09-24 08:22:31

Thank you for the patch. There is a high likelihood that the path will be different from one OS or distribution to another.  It would be good to have a #define and to have it try a few different paths before giving up (especially if we can find more details) and if you are unable to open the termcap file, we should fall back to our internal logic.

By: Steve Davies . (stevedavies) 2004-09-24 08:32:06

My terminfo manpage says:

"Binary Compatibility
      It  is  not  wise  to  count  on portability of binary terminfo entries
      between commercial UNIX versions.  The problem is  that  there  are  at
      least  two  versions  of  terminfo (under HP-UX and AIX) which diverged
      from System V terminfo after SVr1, and have added  extension  capabili-
      ties  to the string table that (in the binary format) collide with Sys-
      tem V and XSI Curses extensions.

Why not use tgetent() and such to work with the terminfo database?


By: Tilghman Lesher (tilghman) 2004-09-24 10:00:52

tgetent(3X) manpage also says:

      The XSI Curses standard, Issue 4 describes these  functions.   However,
      they  are marked TO BE WITHDRAWN and may be removed in future versions.

So that isn't a solution, either.  Personally, I don't think we need to be worried about binary compatibility with either HP/UX or AIX.

By: Tilghman Lesher (tilghman) 2004-09-24 12:21:14

stevedavies:  I reread your bugnote and it's irrelevant.  While other implementations may have altered the string table, we're pulling information out of the num table, not the string table, so as long as they didn't change the number of the headers, this minor binary change to the string table shouldn't affect the num table.  (We're not even parsing the strings header, because that comes after the num header.  Ditto for the strings data -- it comes after the num data.)

By: Tilghman Lesher (tilghman) 2004-09-25 02:39:49

Okay, multiple OS's addressed, and fallback added, although the fallback isn't the same code as was there before.  Note the comments why.

By: Mark Spencer (markster) 2004-09-27 16:26:12

Would be nice to actually try to open each path, something like:

snprintf(path, "foo/%s", term);
fd = open(path, ...);
if (fd < 0) {
  snprintf(path, "bar/%s", term);
  fd = open(path, ...);
if (fd < 0) {
  snprintf(path, "baz/%s", term);
  fd = open(path, ...);

then we can try several paths rather than have it hard coded at compile time.

By: Tilghman Lesher (tilghman) 2004-09-27 22:00:46

Okay, updated.  The code is a little more elegant than your example and more easily updateable with more paths, should that be necessary.  Hope you like it.

By: Mark Spencer (markster) 2004-09-30 23:09:45

Added to CVS

By: Russell Bryant (russell) 2004-10-01 17:50:27

new feature - not included in the 1.0 branch

By: Digium Subversion (svnbot) 2008-01-15 15:08:34.000-0600

Repository: asterisk
Revision: 3867

U   trunk/term.c

r3867 | markster | 2008-01-15 15:08:34 -0600 (Tue, 15 Jan 2008) | 2 lines

Merge Tilghman's color detection patch (bug ASTERISK-2456)