Color output on serial console?

kumba

New Member


Messages: 3

I am trying to get colorized output over a serial console (115200 8n1, ttyu0) on a small network appliance running 12.0-RELEASE. So far, I am not having much luck. I've tried setting CLICOLOR, COLORTERM, and making sure that $TERM is a color-capable value (currently "putty-256color"). ls -lG nor other commands like 'grep' are showing color over the serial console. Is there some switch I have over looked hiding somewhere? I have multiple other systems that use serial which display fine, but they all run Linux. Client system is Windows, and I am using the latest PuTTY release. I've also switched to bash as the main shell for users and root.
 

OJ

Daemon

Reaction score: 286
Messages: 1,083

How much color are you looking for?
You could put this in your .cshrc
set prompt = "\n%{\033[31m%}%/ %{\033[1;33m%}%m%{\033[1;33m%}%% %{\033[0m%} "
set promptchars = "%#"

Edit, oh sorry, I missed the bash part. :(
 

olli@

Well-Known Member
Developer

Reaction score: 276
Messages: 315

There is no definition of “putty-256color” in FreeBSD's termcap. You could try simply “putty” which supports the basic 8 colors, or “xterm-256color” which supports the common 256 color DEC/ANSI palette (I think putty is mostly xterm-compliant, so this should work).

By the way, a simple test to check if your terminal actually supports colors, type this command:
echo $'\e[31;43m foo bar \e[m'
It should display “foo bar” with red letters on yellow background.

Next thing to test is whether your TERM environment variable is set correctly. Use this command:
tput Co
It should output the number of colors supported by the terminal according to your TERM variable. That will be “8” for putty, “256” for xterm-256color, nothing if it doesn't support colors at all (e.g. vt100), or an error message if the TERM variable is set to an unknown value (like putty-256color): “tput: tgetent failure: No such file or directory”

If that is set correctly, then things like ls -lG should work.
 
OP
OP
K

kumba

New Member


Messages: 3

There is no definition of “putty-256color” in FreeBSD's termcap. You could try simply “putty” which supports the basic 8 colors, or “xterm-256color” which supports the common 256 color DEC/ANSI palette (I think putty is mostly xterm-compliant, so this should work).
Sorry, forgot to add that I added a definition for putty-256color to the termcap file and rebuilt it using mkdb, per a comment on this unix.stackexchange.com answer

By the way, a simple test to check if your terminal actually supports colors, type this command:
echo $'\e[31;43m foo bar \e[m'
It should display “foo bar” with red letters on yellow background.
It does.

Next thing to test is whether your TERM environment variable is set correctly. Use this command:
tput Co
It should output the number of colors supported by the terminal according to your TERM variable. That will be “8” for putty, “256” for xterm-256color, nothing if it doesn't support colors at all (e.g. vt100), or an error message if the TERM variable is set to an unknown value (like putty-256color): “tput: tgetent failure: No such file or directory”

If that is set correctly, then things like ls -lG should work.
So this command doesn't output anything at all. Which means it acknowledges the termcap entry I added, but doesn't (for some reason) acknowledge color support. Setting TERM to plain "putty" does, however, report back 8 colors, and ls -lG does show a directory name in color. So there must be something not right with how the putty-256color term entry was generated by infocmp.

This is what infocmp -C putty-256color gives back, and which I appended to the end of the termcap file. I certainly can't make sense of it...old-school terminal encoding sequences read like Klingon to me:
Code:
#       Reconstructed via infocmp from file: /usr/local/share/misc/terminfo.db
# (untranslatable capabilities removed to fit entry within 1023 bytes)
putty-256color|PuTTY 0.58 with xterm 256-colors:\
        :am:bw:hs:mi:ms:xn:xo:\
        :it#8:\
        :AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:K2=\E[G:\
        :LE=\E[%dD:RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:ae=^O:\
        :al=\E[L:as=^N:bl=^G:bt=\E[Z:cd=\E[J:ce=\E[K:cl=\E[H\E[J:\
        :cm=\E[%i%d;%dH:cr=\r:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:\
        :dl=\E[M:do=\ED:ds=\E]0;\007:ec=\E[%dX:ei=\E[4l:fs=^G:\
        :ho=\E[H:im=\E[4h:\
        :is=\E7\E[r\E[m\E[?7h\E[?1;4;6l\E[4l\E8\E>\E]R:\
        :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\
        :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:\
        :kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=\177:kd=\EOB:ke=\E[?1l\E>:\
        :kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:\
        :mb=\E[5m:md=\E[1m:me=\E[0m:mr=\E[7m:nd=\E[C:nw=\r\n:\
        :rc=\E8:rs=\E<\E["p\E[50;6"p\Ec\E[?3l\E]R\E[?1000l:\
        :sc=\E7:se=\E[27m:sf=\n:so=\E[7m:sr=\EM:st=\EH:ta=^I:\
        :te=\E[2J\E[?47l:ti=\E[?47h:ts=\E]0;:ue=\E[24m:up=\EM:\
        :us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:vi=\E[?25l:
 

olli@

Well-Known Member
Developer

Reaction score: 276
Messages: 315

Sorry, forgot to add that I added a definition for putty-256color to the termcap file and rebuilt it using mkdb, per a comment on this unix.stackexchange.com answer
Well, I recommend not to try to create new termcap entries yourself, unless you know exactly how it works. There are several pitfalls.

It is better to use one of the existing terminal entries that fits your terminal best (xterm-256color should work fine, or just putty if 8+8 colors are enough for you). They have been carefully constructed by people who know what they're doing. :)

So this command doesn't output anything at all. Which means it acknowledges the termcap entry I added, but doesn't (for some reason) acknowledge color support. Setting TERM to plain "putty" does, however, report back 8 colors, and ls -lG does show a directory name in color. So there must be something not right with how the putty-256color term entry was generated by infocmp.
Indeed, the termcap entry that you quoted does not contain any color definition. It contains definitions for monochrome attributes only (bold, inverse, blink).
 
OP
OP
K

kumba

New Member


Messages: 3

Well, I recommend not to try to create new termcap entries yourself, unless you know exactly how it works. There are several pitfalls.

It is better to use one of the existing terminal entries that fits your terminal best (xterm-256color should work fine, or just putty if 8+8 colors are enough for you). They have been carefully constructed by people who know what they're doing. :)


Indeed, the termcap entry that you quoted does not contain any color definition. It contains definitions for monochrome attributes only (bold, inverse, blink).
Yeah, it looks like that bit about cutting off at 1023 bytes probably dropped the color definition bits. I'll stick w/ xterm-256color for now. Seems to play nice w/ PuTTY for the time being. Thanks!
 

olli@

Well-Known Member
Developer

Reaction score: 276
Messages: 315

By the way, there is a little script called ansitest that you can find here, along with several screenshots:
http://inof.de/FreeBSD/scripts/ansitest/

If you run it with the -t option, it tells you if your $TERM variable is set correctly, whether it supports color, and how many colors (8, 256, whatever). You can also use the script to run various color tests, including viewing the 256 color palette that most terminals support today. Use the -h option to display the help text.
 
Top