Live data from Hacker News

Colorize Your CLI

danyspin97.org

41–50 of 124 posts

Re: Colorize Your CLI

#41
post #22

Earlier quoted context omitted.

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.

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.

> 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.

Re: Colorize Your CLI

#42

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.

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.

Re: Colorize Your CLI

#43
post #6

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 pos…

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

Re: Colorize Your CLI

#44
post #6

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 pos…

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!

Re: Colorize Your CLI

#46
post #6

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 pos…

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

Re: Colorize Your CLI

#48
post #9

Earlier quoted context omitted.

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 o…

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 standar…

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.

Re: Colorize Your CLI

#49
post #9

Earlier quoted context omitted.

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 o…

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 standar…

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.

Re: Colorize Your CLI

#50
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?
Post reply on HN