
Colorize Your CLI - danyspin97
https://danyspin97.org/blog/colorize-your-cli/
======
GhostVII
I feel like we need a complete rewrite of terminal emulators/bash/whatever. It
should be super easy to make a CLI with nice colors, good loading icons, etc.
without having to deal with all kinds of color codes and cursor movement. When
I press "enter" while a script is showing some progress bar, or resize the
terminal window, it should handle it nicely like every other application.

I use the command line whenever possible over a GUI application, but sometimes
I wish it wasn't still stuck in the 80s. Keep the speed an simplicity (I don't
want images or anything), but make it easy to make robust applications with a
clean text based UI. I shouldn't still have ghosting in my Vim setup, it's
2020.

~~~
mulmen
I kinda like using tooling with 40 years of refinement. Is it perfect? No. Do
I need to resize a window with a progress bar? No. Would it be nice? Yeah, I
guess. Am I underestimating the benefits? Almost certainly.

But what are the other sharp edges that come with the shiny new thing? Would
it be an electron app? Yes, probably. Would it work? Maybe, in a couple years.
There would be some major bugs first, and a lot of dead batteries.

I don’t think new devs are specifically worse than old ones. I do think there
is immense value in using something that has been actively improved for your
(well, at least my) entire lifetime.

There are lessons buried in there we don’t even begin to understand. Starting
over means forgetting those lessons too.

The grass is always greener on the other side of the fence is what I am
saying.

~~~
craftkiller
There still some pretty glaring issues, even after 40 years of refinement.
Some I think could be iteratively fixed but not all of them (for example I
believe #1 requires a significant breaking change to terminals).

1\. You can't have an interactive program in a pipeline. For example, you
can't do `gpg --decrypt foo.txt.gpg | nano | gpg --encrypt` because keyboard
input on the console is handled through stdin. You can work around this by
using a graphical editor in the pipeline, but this should be possible entirely
over the command line.

2\. You can't have hotkeys that are just modifier keys because the modifier
keys only change the byte sent when pressing another key. So could couldn't
have a hotkey "Shift" but you can have a hotkey "Shift-n".

3\. How do you tell the difference between an escape sequence and the escape
key? Escape sequences start with exactly the same byte used by the escape key

4\. While we have escape sequences to move the cursor and detect the cursor
location, in order to find dimensions of the terminal we have to resort to an
ioctl.

5\. Termcap. Because we can't assume some standard set of terminal features,
and since my FreeBSD servers don't have a termcap file for alacritty, when I
ssh into my FreeBSD servers my backspace key doesn't work (along with a lot of
other things).

6\. This ones a bit optional, but it would be nice to have a standard protocol
for telling the terminal to render an image.

7\. Abruptly killing a program that has put the terminal into raw mode leaves
your terminal in raw mode.

What would I do to fix this:

1\. Move keyboard input to a different file handle than pipes. This would
require software to be patched, or at least a compatibility layer written to
merge the pipes for legacy software.

2\. Remap all the keyboard bytes. Every key press and every key up sends data
to the keyboard input stream. Let the program maintain a keyup/keydown state
map for handling modifier keys. This would require software to be patched or
at least a compatibility layer written to remap the bytes.

3\. As part of the new encoding for #2, we should make a better encoding for
input. The current system seems a lot more "grown" than designed. I'd love to
see something similar to UTF-8 where we get to encode a variable-length
integer with the benefits of indicating byte length in the first byte and
being able to detect if we're in a continuation byte. We could even use UTF-8
verbatim for most of the keyboard input but we'd need a special section for
escape sequences like moving the cursor. I don't know enough about unicode to
know if theres a section we could use for that, but worst case scenario we
could use the 5 and 6-byte length utf-8 sequences that never made it to the
final utf-8 spec despite being possible in the encoding.

4\. As part of #3, add escape sequences to detect terminal dimensions.

5\. Establish a new minimum set of features that are assumed to work,
incorporating all these refinements over the past 40 years.

6\. This could be part of the new encoding for #3

7\. Automatically revert terminal to its original non-raw-mode state at the
end of a program.

Finally, I'd recommend this blog post to appreciate how much of a mess
terminal programming is:
[https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode...](https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode.html)

~~~
bacon_waffle
> since my FreeBSD servers don't have a termcap file for alacritty, when I ssh
> into my FreeBSD servers my backspace key doesn't work (along with a lot of
> other things).

A hack I've got in .zshrc for this problem:

    
    
      function ssh {
       if [[ "${TERM}" = alacritty ]]; then
        env TERM=xterm-256color /usr/bin/ssh "$@"
       else
        /usr/bin/ssh "$@"
       fi
      }

~~~
ac29
Installing the terminfo also works:
[https://github.com/alacritty/alacritty/blob/master/INSTALL.m...](https://github.com/alacritty/alacritty/blob/master/INSTALL.md#terminfo)

~~~
fiddlerwoaroof
Yeah, I create a .terminfo directory in my home folder on any box I ssh to and
make sure it has the terminfo for the terminal I use.

------
IggleSniggle
One of the biggest upgrades from using fish is syntax highlighting /
autocompletion. You can get fish-style syntax highlighting and autocomplete in
zsh (which has the advantage of being more interoperable with bash generally):

[zsh-syntax-highlighting]([https://github.com/zsh-users/zsh-syntax-
highlighting](https://github.com/zsh-users/zsh-syntax-highlighting))

[zsh-autosuggestions]([https://github.com/zsh-users/zsh-
autosuggestions](https://github.com/zsh-users/zsh-autosuggestions))

Poster mentioned "modern alternatives exist" with good colorization options.
Some of my favorite colorized feature-rich alternatives:

ls -> [exa]([https://github.com/ogham/exa](https://github.com/ogham/exa))

cat -> [bat]([https://github.com/sharkdp/bat](https://github.com/sharkdp/bat))

du -> [ncdu]([https://dev.yorhel.nl/ncdu](https://dev.yorhel.nl/ncdu))

diff ->
[delta]([https://github.com/dandavison/delta](https://github.com/dandavison/delta))

In combination with all of the above,
[fzf]([https://github.com/junegunn/fzf](https://github.com/junegunn/fzf))
suddenly becomes a syntax-highlighter preview-pane via leveraging bat (or
delta, as the case may be).

~~~
danyspin97
Poster here! ble.sh gives syntax highlighting for bash just like fish and zsh.
I personally don't like zsh because it seems over engineered and fish have
some design problems (I don't think they have yet fixed them).

The feature-rich alternatives you mentioned are exactly what I was thinking
about (and using daily!).

~~~
IggleSniggle
There are a few things about zsh that "feel better" than bash (especially
arrays), but given the ubiquity of bash, if I can get the same general
quality-of-life upgrades that I experience from the zsh community add-ons, I
may need to give ble.sh a go.

Edit: I gave ble.sh a try, and it is super-cool-magic, but does feel slow with
quite noticeable input lag.

------
samsaga2
As developer I think we use too many colors everywhere. It is really
necessary? Some terminals looks like a rainbow festival.

A color for the user, a different color for the hostname, another one for the
git branch... It is a directory? Let's add a new color. I think is too much.

I like to use themes like minimal-theme [[https://github.com/anler/minimal-
theme](https://github.com/anler/minimal-theme)]. My eyes appreciate it.

~~~
sgt
I agree. How about just reading the text? The human brain is excellent at
quickly skimming through text and recognizing patterns. We don't need colors.

~~~
nomel
Differentiating by, and extracting meaning from, color is a very ancient and
important part of our visual system and every day life. Why wouldn’t you want
to take advantage of it, living in a black and white world?

------
Tade0
Somewhat related:

My friend is developing a colour palette based on Solarized:

[https://github.com/jan-warchol/selenized](https://github.com/jan-
warchol/selenized)

but with more perceptual uniformity.

~~~
tvb12
It looks like he's only doing the dark mode. I wonder what selenized-light
would look like.

~~~
O_H_E
Take a look here: [https://github.com/jan-warchol/selenized/blob/master/the-
val...](https://github.com/jan-warchol/selenized/blob/master/the-values.md)

------
atdt
The GitHub link to Generic Colouriser points to an outdated and unofficial
fork. The canonical one is at
[https://github.com/garabik/grc](https://github.com/garabik/grc).

~~~
danyspin97
Fixed, thanks you for pointing this out!

------
roywiggins
Colorful prompts remind me of my time playing MUDs. The better ones did a good
job colorizing everything so you could navigate almost by color alone.

------
pen2l
I think in this day and age we should be making bigger jumps than wanting
color in our CLI.

We should have more than one font, we should have pictures. We're visual
creatures, us humans. I think something like Jupyter, with in-line images et
al is the future, or should be, at least.

~~~
Icathian
I strongly disagree. If we're going to use a TUI, it should embrace what it
is. Turning it into a watered down GUI does not work to its strengths nor
serve the needs of the users still working with it.

~~~
smabie
I dunno, Emacs works really well, and I line images and stuff is really nice.
A good example of this is that you can have inline rendered LateX in your text
buffer. And when you need to edit it, it turns about into texts.

Also inline graphs in org-mode is super nice.

------
IshKebab
Also set `CLICOLOR=1`. See
[https://bixense.com/clicolors/](https://bixense.com/clicolors/)

A fair number of tools support it.

------
oweiler
Instead of `ls` I use `lsd`
[https://github.com/Peltoche/lsd](https://github.com/Peltoche/lsd).

~~~
makeworld
How does this compare to exa?

[https://the.exa.website/](https://the.exa.website/)

~~~
oweiler
`exa` provides more functionality but is also much slower.

------
clintonc
I find myself wishing for a CLI "design system". For example, given a script
that calls some APIs (reads and writes) and does a couple of calculations,
what is the best way to use color and space to produce understandable and
useful console output?

------
monokh
Really tempted to install starship but I also do a bunch of sensitive stuff
with my terminal. Should I be worried about using this? I understand it's open
source, yet still not confident.

~~~
danyspin97
Keep in mind that having bash history is already a treat since
`~/.bash_history` is readable by every program you run.

If you want to be 100% safe you could just monitor the process and see if it
opens any internet connection but I am confident it is just a local program.

~~~
O_H_E
> treat

*threat

------
eddieh
I do like to have colorized output for my interactive CLI tools, but I will
never understand a prompt other than "$" or "#".

Do people really need to continuously see all the noise like the host name,
their username, the working directory, the date, or even their current branch?

Is hostname, whoami, pwd, date, git branch, and git status really to
cumbersome? At least with hostname and branch I'm usually piping to pbcopy
anyway.

FWIW, the -F option for ls is really nice too.

~~~
CamperBob2
_Do people really need to continuously see all the noise like .... the working
directory...?_

I can't imagine using a CLI prompt without knowing what directory I'm in. How
would that even work?

~~~
eddieh
I guess I usually know what directory I'm in and if I ever need a reminder I
use pwd.

With at least 6 months of commands in ~/.bash_history

$ history | grep pwd | wc -l

    
    
          10

~~~
kergonath
I usually have ~20 terminal windows open, some of which have sessions opened
on 4 different machines. If the host name and current working directory are
not in the prompt, I need to check both every time I switch windows. Otherwise
there’s no way I won’t make a mistake and do some stuff in the wrong place or
on the wrong server.

I can accept that my use case is not typical, but these things are actually
useful.

------
ausjke
Nice article, 'starship' is new to me, just tried out, a bit verbose and took
too much line space for me. 'highlight' should be replaced by 'bat' these
days. 'grc' is nice and I first time learned it here. After read it and tried
out, I just added 'grc' to my tool kit(though ubuntu 18.04 misses
/etc/profile.d/grc.bashrc and I had to download it from github)

~~~
always_left
Just looking at the homepage of starship, I don't really understand what
benefits it has. It says fast but simply has a gif? I understand a bit more
via the docs, but it's annoying the home page doesn't really show any benefits
and just wants you to install it asap.

------
rudiv
Love starship. Fast, easily customizable, and best of all works on Windows as
well as macOS/Linux. (Unsure about BSD, but I presume that as well)

------
AlexDragusin
For Windows, one could use this small color utility I've made last year,
ColorThis

[https://www.alexdragusin.com/#ColorThis](https://www.alexdragusin.com/#ColorThis)

------
dleslie
Colorizing is a red herring; it's akin to syntax highlighting: it's nice, but
if you need it to determine important information then something's amiss.

I'd much prefer consistent and predictable information conveyance. Ie, I don't
need Midnight Commander to be lit up like a christmas tree because I know
immediately what information is displayed in its tables and panes.

~~~
a1369209993
> but if you need it to determine important information then something's
> amiss.

Not untrue, but define "need"; as eg [0] points out, distinctive colors make
it _much_ easier to notice things. (On the other hand, TFA seems to be
advocating precisely the kind of syntax-based ice-cream-sprinkle-soup coloring
that makes it _harder_ to notice things, so not exactly the most convincing
presentation there.)

0: [https://buttondown.email/hillelwayne/archive/syntax-
highligh...](https://buttondown.email/hillelwayne/archive/syntax-highlighting-
is-a-waste-of-an-information/) 0 dicussed:
[https://news.ycombinator.com/item?id=23902124](https://news.ycombinator.com/item?id=23902124)

~~~
dleslie
Colour is a bad tool, even if it is an effective tool; a not-insignificant
portion of the population has difficulties with colour. Then there's that not
all displays render the same, and not all editors colourize the same. Syntax
and layout are superior.

~~~
a1369209993
I am _immensely_ opposed to the notion that something being difficult or even
wholely unusable for a "not-insignificant portion of the population" makes it
a bad tool, rather than merely a situational one to which alternatives are
also necessary[0]. The same reasoning, applied to the not-insignificant
portions of the population with more severe disabilities than color-blindness,
would condemn very nearly every tool in the history of technological
civilization.

0: And in this case - as you yourself have pointed out - happily available.

~~~
dleslie
The necessary alternatives, in CLI, are consistent and human readable syntax
in a consistent and pleasing layout; and those alternatives are generally
either present or not.

Moreover, they're useful to anyone regardless of their ability, and consistent
syntax is easier to automatically colourize. Starting with colourizing is
backwards.

~~~
a1369209993
At what point did I suggest _starting_ with colorizing? I pointed out that[0]
colorizing was sometimes so effective at drawing attention to important
information that it was reasonable to describe it as needed, with the
implication that coloring should be available _in addition_ to other
information channels.

0: for some people, which I perhaps should have explicitly noted, but it
really ought to go without saying that no tool is equally effective for
everyone.

~~~
dleslie
You didn't; and neither did I suggest that colorizing was ineffective. It's
bad because when using other tools it's unnecessary.

------
vyrotek
Microsoft's new Terminal is really customizable

[https://devblogs.microsoft.com/commandline/windows-
terminal-...](https://devblogs.microsoft.com/commandline/windows-
terminal-1-0/)

~~~
digisign
Welcome to the 80s & 90s. :D

~~~
WorldMaker
Better late than never. :)

------
tzury
`diff --color=auto` is nice, but `vimdiff` is superior

~~~
ipozgaj
There is also `colordiff` which works both as a standalone diff tool, but also
as a colorizer filter for other diff tools. For example:

    
    
      diff -u a.txt b.txt | colordiff

~~~
petepete
Git ships with `diff-highlight` which is more than enough for me.

I use the following config.

    
    
        [core]
          pager = /usr/share/git-core/contrib/diff-highlight | less
    
        [color "diff-highlight"]
          oldNormal = red
          oldHighlight = 16 bold red
          newNormal = green
          newHighlight = 16 bold green

