Created attachment 252599 [details] remove AB= and AF= values from xterm-256color termcap entry I noticed that when setting my TERM environment variable to xterm-256color, the bright (bold) xterm colors (color9-color14) no longer worked for ncurses apps in Xterm. I found this old Usenet post which seems to imply that some Linux distros made a similar patch to their termcap databases long ago: https://tmux-users.narkive.com/o6kjUfcW/bold-colours-and-xterm-256color#post10 The attached patch for /etc/termcap allows the "bright" colors to display properly in ncurses apps again. To reproduce: 1. Install profanity (xmpp ncurses app): pkg install profanity 2. In an XTerm, run `TERM=xterm-256color profanity` 3. At the profanity prompt, type `/theme colours` and press <Enter> 4. Notice that the "bold_" colors are rendered with the same color as the non-bold colors. To apply the fix: 1. Apply the attached patch to /etc/termcap 2. Run `cap_mkdb -f /usr/share/misc/termcap /etc/termcap` 3. Repat the above steps in profanity and notice that the bold colors are now displayed properly.
(In reply to Cullum Smith from comment #0) > 2. Run `cap_mkdb -f /usr/share/misc/termcap /etc/termcap` I didn't need this step. Also with patched termcap "export LSCOLORS=Exfxcxdxbxegedabagacad" start to work for me with TERM=xterm-256color in x11/konsole!
(In reply to Vladimir Druzenko from comment #1) > I didn't need this step. Confirmed. I had done so since the comments at the top of /etc/termcap seemed to imply it was necessary, but it seems not. It took me hours to figure this out, my first clue was that the full 16 colors worked in tmux inside xterm, but not plain xterm. Not sure if this change would have an effect on very old curses apps or not. I have tested it with all my regular ncurses/CLI apps and have not noticed any issues.
Actually, do *not* merge this patch. It fixes color9-color14 but breaks the display of 256 colors in ncurses. I'll keep looking.
While I lack the inclination to grok all the arcane details of termcap/terminfo, after comparing the `infocmp` output for xterm-256color with a Linux system, I believe I understand the problem. Termcap appears to be an older/less expressive format compared to terminfo. FreeBSD's terminfo seems to have a termcap compatibility layer, and reads all the termcap definitions from /etc/termcap. xterm appears to have a quirk that requires some special handling in 256-color mode. On my Linux system, the setaf/setab values for xterm-256color look like this: setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m, setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m, I do not fully understand this line noise, but it appears to have some special logic for values in between 8 and 16 (the bright colors?) You can't blindly copy this into the xterm-256color definition in /etc/termcap, because the termcap format seems to lack support for whatever syntax this is. However, you can compile a terminfo override and it appears to take precedence over /etc/termcap. Running the shell fragment below allows bright colors to work in xterm-256color while maintaining full 256 color capability. # The following was blindly copied from a 'infocmp xterm-256color' on a linux host. cat <<'EOF' > /root/xterm-256color.terminfo xterm-256color|xterm with 256 colors, am, bce, ccc, km, mc5i, mir, msgr, npc, xenl, colors#0x100, cols#80, it#8, lines#24, pairs#0x10000, acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l, clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A, cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m, dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS, initc=\E]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\, invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, ka1=\EOw, ka3=\EOy, kb2=\EOu, kbs=^?, kc1=\EOq, kc3=\EOs, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q, kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~, kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~, kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~, kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S, kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~, kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~, kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q, kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~, kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~, kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~, kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q, kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~, kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~, kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~, kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~, kind=\E[1;2B, kmous=\E[<, knp=\E[6~, kpp=\E[5~, kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El, memu=\Em, mgc=\E[?69l, nel=\EE, oc=\E]104\007, op=\E[39;49m, rc=\E8, rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l, rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l, rmkx=\E[?1l\E>, rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m, rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7, setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m, setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m, sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m, sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h, smcup=\E[?1049h\E[22;0;0t, smglr=\E[?69h\E[%i%p1%d;%p2%ds, smir=\E[4h, smkx=\E[?1h\E=, smm=\E[?1034h, smso=\E[7m, smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c, u9=\E[c, vpa=\E[%i%p1%dd, EOF tic -o /usr/local/share/site-terminfo /root/xterm-256color.terminfo
(In reply to Cullum Smith from comment #4) > FreeBSD's terminfo seems to have a termcap compatibility layer ncurses in FreeBSD >= 14 enabled terminfo support (base 61f66a1f4403) but due to POLA (backlash?) still uses homegrown termcap database by default. Users seeking advanced terminfo-only features (or Linux-style defaults) are expected (base b75fb12b6827) to install misc/terminfo-db. CC @bapt as misc/terminfo-db looks barely documented anywhere. > special handling in 256-color mode. 0-7 are regular colors, compatible with vt100-color. 8-15 are bright colors, compatible with xterm-16color. From xterm-256color source: # This implementation uses a 256-element color map where the first 16 entries # are shared with the aixterm-compatible colors (and in turn the first 8 are # shared with the ANSI colors). The three levels (256, 16, 8) account for the # use of a conditional expression in setaf/setab which reduces the number of # characters sent to the screen for typical applications. From xterm(1) manpage: boldColors (class ColorMode) Specifies whether to combine bold attribute with colors like the IBM PC, i.e., map colors 0 through 7 to colors 8 through 15. These normally are the brighter versions of the first 8 colors, hence bold. The default is "true". > setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m, terminfo(5) manpage explains the syntax. Basically, 0-7 colors use \E[3<arg>m, 8-15 colors use \E[9<arg-8>m while the rest use \E[38;5;<arg>m $ tput setaf 6 | od -a 0000000 esc [ 3 6 m 0000005 $ tput setaf 14 | od -a 0000000 esc [ 9 6 m 0000005 $ tput setaf 22 | od -a 0000000 esc [ 3 8 ; 5 ; 2 2 m 0000012
Thanks for the detailed explanation. Installing terminfo-db indeed resolves the issue. I suppose this issue can be closed, since it sounds like termcap is functioning as designed.