Discussion: Colorize your BSD shell

  • Thread starter Thread starter Deleted member 81054
  • Start date Start date
D

Deleted member 81054

Guest
[Mod: Split the discussion of the howto: https://forums.freebsd.org/threads/colorize-your-bsd-shell.85458/]

mer said:
I hate the colorization stuff being turned on by default. Hurts my eyes and actually hides the data from me.
Click to expand...
+42

It reeks of a newbie using ten different "fonts" in a document -- just because he CAN.

IMO (having prepared online and print documentation for decades), one should concentrate on BOLD, BLINK (rarely!) and UNDERLINE (in print, you can add italics) -- and eschew colors.

Also, ~7% of men are colorblind so YOUR choice of colors may not benefit (and may hinder) their comprehension (and, your eyes focus on colors at different "distances").
 
Last edited by a moderator:
kpedersen said:
Very helpful hints on how to fix misbehaving programs that are color by default and don't support NO_COLOR.
Click to expand...
Only for CLI-type I/O.

Dealing with the presence of color in GUIs is more difficult as mapping to monochrome may not be possible. (and, GUI versions of text interfaces -- e.g., the installer -- are increasingly common). "Daltonize"
 
Don Y said:
Only for CLI-type I/O.
Click to expand...
Indeed. Luckily that is my main interest. Anything that we can shovel through SSH / serial is what I prefer to see without color.

Traditional desktop GUI seems to be dying and being replaced with crappy web apps. I suppose I don't care what colors people use at that point.
Don Y said:
and, GUI versions of text interfaces
Click to expand...
You mean TUI right? The FreeBSD installer just presents prompts through a "dialog" compatible program. This has quite a lot of flexibility built in for color choices (or lack of). TUI is generally fine, albeit a bit buggy over some serial setups.
 
kpedersen said:
Indeed. Luckily that is my main interest. Anything that we can shovel through SSH / serial is what I prefer to see without color.
Click to expand...
That is one of my biggest annoyances: ssh into a system to debug a problem, you script the session and colors put all kinds of binary codes into the file. Makes grepping not fun and open in an editor? WTF am I looking at.
 
kpedersen said:
You mean TUI right? The FreeBSD installer just presents prompts through a "dialog" compatible program.
Click to expand...
In the case of the FBSD installer, yes. But, increasingly, services are being presented via GUI-like interfaces.

E.g., the maintenance interfaces for my servers want to pretend to be "Windows". It's mainly text. But, THEY have decided what color scheme to use, typefaces, etc. If I don't like their choices, I have to drag out a serial console (and HOPE the interfaces are functionally equivalent).

When I want to talk to a UPS, it tries to similarly pretend to be a GUI. Or, my scanners. Or...
 
just an opinion, but don't! One of my many old guy curmudgeon pet peaves is all the hardcoded colorization of command line output (especially in the GNU world) that has been creeping into utilities in recent years. It's a bad concept and should be avoided. I use xterm color schemes to keep track of sessions on several concurrent servers and it really grind my gears when I cannot read the output on half of them because some script-kiddie thought it was a good idea to build in their preferred multi-color scheme in the program output.
 
Any program that colorizes needs to check whether stdout is a terminal, and turn it off when not. That takes care of the problem of output going into files, and it is easy to do. In theory, they should also check whether the terminal type supports ANSI sequences, but in practice, that's no longer necessary (Hazeltines and ADM3A are no longer in real-world use). Plus honoring NO_COLOR is trivial too. Also, when colorizing one has to be careful and tasteful, because some decisions don't work well on both dark and light background; for example yellow really stands out on a dark background, but is nearly invisible on a light background. Also beware of the combination of bold and colors, as some emulators don't implement bold fonts, and instead change the color to "brighter", which can make it less visible on a white background.

In my personal code, I even used to turn off unicode when stdout is not a terminal. Today, I leave it on, since I assume every application (including grep and emacs) can handle it correctly. And it is so convenient to be able to print "Pumphouse 49.5°F Recent change +1.4°F/hour χ²ₙ=0.19"
 
kent_dorfman766 said:
It's a bad concept and should be avoided.
Click to expand...
It's just silly. The information that it is trying to REDUNDANTLY convey is already there. What happens when the user accustomed to "colorizing" has to work in an environment that doesn't support it? OhMiGosh!

Also, it relies on the developer to decide what merits distinct colors. What if some other criteria is important to me? Why haven't my needs been addressed?!
kent_dorfman766 said:
I use xterm color schemes to keep track of sessions on several concurrent servers and it really grind my gears when I cannot read the output on half of them because some script-kiddie thought it was a good idea to build in their preferred multi-color scheme in the program output.
Click to expand...

I used to use this approach with VTYs. So, I could associate a particular color with some activity that I was performing. E.g., the red console is where I am building the kernel; the green one is where I am modifying the config file for the next kernel attempt (notice how little value color added, there?)

It also burdens support for assistive technology because developers look to this other "data channel" to convey information instead of putting it in the original data channel where AT tools can extract it.

Spend the time/effort that you would be tempted to spend on colorizing your output on ENSURING there are ZERO bugs in your code (notice how bold makes that point without relying on color?).
 
Set TERM to vt200, and you don't get colors. Just tested it and it works. Unfortunately, you still get boldface versus regular.

Obviously, the "right" solution would be to write lisp in the .emacs file. Since I find lisp icky, I don't even want to investigate that. I know my desk neighbor spent hours on playing with font-lock-mode to get the colors "just right", but it needs to be redone over and over, for each programming language.
 
Hmmm, I thought I set my $TERM to something pre-color and still got colors in Emacs' SLIME mode. But now I can't reproduce either.
 
You must log in or register to reply here.
Back
Top