[HN Gopher] Colorize Your CLI
___________________________________________________________________
Colorize Your CLI
Author : danyspin97
Score : 147 points
Date : 2020-07-26 14:34 UTC (8 hours ago)
(HTM) web link (danyspin97.org)
(TXT) w3m dump (danyspin97.org)
| Tade0 wrote:
| Somewhat related:
|
| My friend is developing a colour palette based on Solarized:
|
| https://github.com/jan-warchol/selenized
|
| but with more perceptual uniformity.
| samsaga2 wrote:
| 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]. My eyes appreciate it.
| sgt wrote:
| 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.
| CapsAdmin wrote:
| Sounds like the problem is not colors, but the amount of stuff
| we're differentiating then. You could say the same thing about
| making things bold, italics, shades of grey, etc.
|
| I would think people recognize different colors better than
| shades of grey or bold text though.
|
| Interestingly, in a lot of Japanese advertisement it feels like
| all the ways of making something stand out have been exhausted.
| [deleted]
| GhostVII wrote:
| 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.
| IshKebab wrote:
| I agree. Nushell (https://github.com/nushell/nushell) is the
| best I have seen so far. It still lives in a standard terminal
| from the 80s - basically no graphics, limited mouse support,
| etc. But I guess you can't change everything at once. It's an
| enormous improvement on Bash at least!
| clon wrote:
| I am not looking forward to using a new improved shell written
| in JS.
| vkou wrote:
| I rarely look forward to using the old, crufty shell, but I'm
| a madman who would like things like arrow keys and backspace
| and maybe even box select to actually work in a sane manner.
|
| I don't need spreadsheets and rich markup in my terminal. I
| just want basic HCI to work - consistently.
| theshetty wrote:
| I can't agree more!!!
|
| I wrote this simple SAS program/job scheduler
| (https://github.com/PrajwalSD/runSAS) using just bash script
| (with few utils) intentionally to allow for maximum adoption in
| projects and just made it more more colorful. In short 75% of
| the code in there is just handling the terminal (keys, scroll,
| progress bar etc.) and 25% is the actual load balancing logic.
| nurpax wrote:
| Inline images would be great too (bitmap or svg). There'd be a
| lot less need for something like jupyter if you could show
| images in the shell.
| thih9 wrote:
| > I feel like we need a complete rewrite of terminal
| emulators/bash/whatever.
|
| A complete rewrite would be an opportunity to overlook
| important ideas, compromise on goals and make design mistakes.
|
| I'd strongly prefer slow, iterative approach here.
| kjeetgill wrote:
| To use a tortured metaphor: Like any pathfinding problem,
| sure slow and iterative is an important part of the algorithm
| but so is backtracking.
|
| I'm inclined to "if it ain't broke don't fix it", but it's
| also just as true that this greedy algorithm just leaves us
| at a local optima.
| rozab wrote:
| I've spent a lot of time messing with terminal UIs, and I feel
| that the experience could be improved hugely just by adding a
| couple new escape sequences, for right aligned text and for
| filling to the rest of the width of the terminal with a
| character. Thanks to terminfo this shouldn't affect backwards
| compatibility.
|
| I certainly don't think a full rewrite is necessary (we managed
| to tack on mouse support and even image rendering[0] no
| problem). Curses is a pain to work with directly, but this is
| not the fault of terminals or shells. It's really easy to
| create curses interfaces with libraries like blessings[1].
|
| [0]: http://blog.z3bra.org/2014/01/images-in-terminal.html
|
| [1]: https://github.com/erikrose/blessings
| enriquto wrote:
| Oh, please, no "color codes".
|
| Some of us prefer a monochrome terminal, with the only
| distinction being bright/bold and regular text. I'm all for
| modernizing the classical unix tools, but turning them into
| kitsch Christmas trees is maybe not the best way.
| mulmen wrote:
| 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.
| michaelmure wrote:
| It looks to me that the reality is closer to "40 years of
| hack over something that was not meant to be a standard (a
| popular hardware terminal from the 80s)".
|
| I'll give you just one example of the madness that is
| sometimes required: the escape code \e[1m is doing "bold on".
| It's counterpart to reset \e[21m, is supposed to do "bold
| off", but in practice some terminals do "double underline"
| instead because this standard is not a real standard. As
| there is also no real way to detect capability, the only
| reliable way to do "bold off" that I could find is to
| intercept the stream of data sent to the terminal to compute
| the attribute state. When you want to do a "bold off" you do
| a \e[0m "reset all" instead and sent the control character to
| set the state again without bold [1].
|
| A new standard would also allow to reliably use features like
| displaying images or links.
|
| [1] https://github.com/MichaelMure/go-term-
| markdown/blob/master/...
| IncRnd wrote:
| Not using bold properly means the terminal was written
| incorrectly, or the wrong termcap is being used to emulate
| a different terminal.
|
| This isn't a bug with escape codes or with terminals that
| work. It is either that someone doesn't know which teminal
| they are using, or there is a bug in that specific
| terminal.
| spijdar wrote:
| So, what you're saying is, since there are too many
| competing and incompatible standards, what we need is
| another incompatible standard? :)
|
| There are a lot of "better" terminal emulator standards out
| there. The problem is you need software that uses them.
| Perhaps this is the real "refinement" spoken of before --
| these quirks are generally understood and software layers
| are built on top of them to abstract away the ugliness
| while keeping broad compatibility.
|
| There are lots of ideas on how to make a better CLI -- from
| Plan9's rio/window to various XML/DOM based terminal
| emulator, to a smorgasbord of xterm-but-added-features
| emulators that add support for anything from inline images
| to transmitting entire files over the TTY. Ultimately,
| these are only as useful as the software that uses them,
| which often ends up being just a few tools the terminal
| emulator itself ships with.
|
| Even Windows' alternative to TTYs has basically been
| supplanted by an xterm/VT-ish compatible TTY style
| interface for software compatibility reasons.
| thih9 wrote:
| I'd say all this is a feature.
|
| This means that it's difficult to write a flashy app with
| bold text, links and images.
|
| I like programs with minimal text ui, so I don't mind.
| michaelmure wrote:
| A new standard would also make it easier to fallback to
| no colors/decoration if the user wish so. At the moment,
| there is no way to do that without a flags or similar for
| each app. Even detecting if the terminal support colors
| is a pain.
| thih9 wrote:
| > fallback to no colors/decoration if the user wish so
|
| Fallbacks are frequently not implemented, not tested or
| not supported as well as the main feature.
|
| > Even detecting if the terminal support colors is a
| pain.
|
| As the end user, I don't mind. This means that I'll see
| colors only when it's important.
| cuddlecake wrote:
| There are a lot of "Maybe"s in your second paragraph.
|
| I'd say, yes, there are a lot of lessons buried in old code,
| but often, there is an equal amount of baggage we are too
| fearful to abandon because of backward compatibility and "bug
| became feature"-situations.
|
| And even then, it's not you who is abandoning that, which
| makes the attitude even more baffling to me.
| craftkiller wrote:
| 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...
| eitau_1 wrote:
| Here's a proposal to fix #2 and #3:
| http://www.leonerd.org.uk/hacks/fixterms/
| jclulow wrote:
| With respect to interactive programs in a pipeline, this
| can already work today if the software is written to allow
| it. While it is common for interactive software to use the
| standard descriptors for I/O they are not required to. You
| can instead open the magic device, /dev/tty, which gets you
| new handles to the controlling terminal for the process.
| a1369209993 wrote:
| > For example, you can't do `gpg --decrypt foo.txt.gpg |
| nano | gpg --encrypt` because keyboard input on the console
| is handled through stdin.
|
| I actually had a alias at one point that did something
| along the lines of (IIRC): | editor | -> |
| editor -i /dev/fd/3 -o /dev/fd/4 3<&0 4>&1 0<&2 1>&2 |
|
| Since stderr (aka &2 aka /dev/pts/whatever) is opened read-
| write, you can dup it onto stdin to recover the terminal.
| Ideally, every editor should just support reading from
| stdin, interacting via stderr[0], and writing to stdout as
| a command line option though.
|
| Edit: 0: or /dev/tty as jclulow suggested.
| vkou wrote:
| > I kinda like using tooling with 40 years of refinement
|
| I would not call the modern terminal the result of 40 years
| of refinement - mostly for the reasons outlined by the parent
| poster, as well as those of the sibling posters.
|
| If you look at the modern terminal through fresh eyes, 'buggy
| and inconsistent and clunky' would be how the average homo
| sapiens would describe it.
|
| Just because there are reasons for why all of these warts are
| in place, doesn't mean that the program is not defective, as
| designed.
| eitau_1 wrote:
| I treated myself a deep dive into how CLIs work some time ago
| and features like:
|
| * marking output from stderr different color (and don't
| interfere with commands's own formatting much);
|
| * passing more involved keyboard shortcuts to the shell or a
| tui program, etc.;
|
| * making last line of last command usable in next command or
| putting it to clipboard without mouse;
|
| * general awareness of shell/terminal emulator of what's
| displayed (prompt, edited line, commands printing in parallel,
| stdout vs stderr, messages of shell (jobs))
|
| are very tricky to achieve without reorganizing the whole stack
| of terminal emulator, shell, line discipline/readline and even
| kernel.
|
| [0] http://www.linusakesson.net/programming/tty/index.php
|
| [1]
| https://utcc.utoronto.ca/~cks/space/blog/unix/TTYLineDiscipl...
|
| [2] https://github.com/sickill/stderred
|
| [3] http://www.leonerd.org.uk/hacks/fixterms
|
| [4] https://domterm.org/Wire-byte-protocol.html
| monokh wrote:
| 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.
| matchai wrote:
| Starship maintainer here. I'm happy to answer any questions
| have about how it works.
|
| Every render of the prompt is fully stateless. Starship has no
| tracking, telemetry, and never calls home. :)
| danyspin97 wrote:
| 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.
| AlexDragusin wrote:
| For Windows, one could use this small color utility I've made
| last year, ColorThis
|
| https://www.alexdragusin.com/#ColorThis
| ausjke wrote:
| 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)
| IshKebab wrote:
| Also set `CLICOLOR=1`. See https://bixense.com/clicolors/
|
| A fair number of tools support it.
| roywiggins wrote:
| 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.
| IggleSniggle wrote:
| 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)
|
| [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)
|
| cat -> [bat](https://github.com/sharkdp/bat)
|
| du -> [ncdu](https://dev.yorhel.nl/ncdu)
|
| diff -> [delta](https://github.com/dandavison/delta)
|
| In combination with all of the above,
| [fzf](https://github.com/junegunn/fzf) suddenly becomes a syntax-
| highlighter preview-pane via leveraging bat (or delta, as the
| case may be).
| danyspin97 wrote:
| 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 wrote:
| 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.
| atdt wrote:
| The GitHub link to Generic Colouriser points to an outdated and
| unofficial fork. The canonical one is at
| https://github.com/garabik/grc.
| danyspin97 wrote:
| Fixed, thanks you for pointing this out!
| eddieh wrote:
| 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.
| xiconfjs wrote:
| about hostname in the prompt: if you are logged in to a bunch
| of server debugging a problem, it's good to see from the first
| sight on which system you are executing a command.
| enriquto wrote:
| > I will never understand a prompt other than "$" or "#"
|
| I agree with that, but some legit useful information in the
| prompt is the exit status of the previous command. So you may
| have a slightly less minimalist PS1='$?\$ ' which is typically
| seen as "0$" unless something went wrong. Another legit and
| useful information is the number of background jobs (set up to
| the empty string for the common case of zero jobs). Other
| information like the cwd, the time or the git branch are of
| course idiotic.
| isatty wrote:
| For my local machines I don't bother with hostname, whoami or
| date but the former two is essential on remote servers, so it's
| good to have as defaults.
|
| pwd is really useful since I've tons of terminals on tmux and
| typing pwd gets repetitive real quick.
| CamperBob2 wrote:
| _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?
| pen2l wrote:
| 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 wrote:
| 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.
| bmn__ wrote:
| http://blog.z3bra.org/2014/01/images-in-terminal.html
|
| https://askubuntu.com/questions/97542/how-do-i-make-my-termi...
| danyspin97 wrote:
| I agree, but we're limited by terminal emulators. Not counting
| images in terminal (which can be done with a protocol few
| terminal supports), we don't even have Font Ligatures widely
| available.
|
| https://github.com/tonsky/FiraCode#editor-compatibility-list
| tzury wrote:
| `diff --color=auto` is nice, but `vimdiff` is superior
| ipozgaj wrote:
| 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 wrote:
| 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
| erichdongubler wrote:
| I myself have really enjoyed `delta` and the variety of
| configuration it has: https://github.com/dandavison/delta
| clintonc wrote:
| 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?
| rudiv wrote:
| 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)
| oweiler wrote:
| Instead of `ls` I use `lsd` https://github.com/Peltoche/lsd.
| makeworld wrote:
| How does this compare to exa?
|
| https://the.exa.website/
| oweiler wrote:
| `exa` provides more functionality but is also much slower.
___________________________________________________________________
(page generated 2020-07-26 23:00 UTC)