Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Colorize Your CLI

danyspin97.org

Post reply on HN
Print view View original

71–80 of 124 posts

Re: Colorize Your CLI

#71

Post by oddlama »

spijdar wrote: post #49
michaelmure wrote: post #19

Earlier quoted context omitted.

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

Relevant xkcd: https://xkcd.com/927/

Re: Colorize Your CLI

#72

Post by smabie »

Icathian wrote: post #7
pen2l wrote: post #3

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.

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.

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.

Re: Colorize Your CLI

#73

Post by [deleted] »

michaelmure wrote: post #19
mulmen wrote: 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…

[deleted]

Re: Colorize Your CLI

#74

Post by ac29 »

bacon_waffle wrote: post #68
craftkiller wrote: post #28

Earlier quoted context omitted.

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…

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

Installing the terminfo also works: https://github.com/alacritty/alacritty/blob/master/INSTALL.m...

Re: Colorize Your CLI

#75

Post by dmitryminkovsky »

mulmen wrote: post #9
GhostVII wrote: 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 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…

I definitely enjoy the continuity, call me small-minded but I don’t want to see this stuff revolutionized either. Maybe because I came up in the 90s and am nostalgic for the VT220 etc, I don’t know. And it’s weird because I have little or no love for other old school stuff.

Re: Colorize Your CLI

#76

Post by spc476 »

michaelmure wrote: post #19
mulmen wrote: 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…

I hate to say it, but the standard for C1 escape codes, ECMA-48, does list "\e[21m" as "double underline". I can see where one might think it does a "bold off" but alas, that isn't in the standard.

The standard also has a lot of redundancy, and some omissions (getting the size, but I think it was standardized long before TTYs were resizable).

A standard is a good idea, but I think ECMA-48 was a draft that was put into production too quickly.

Re: Colorize Your CLI

#77

Post by skissane »

craftkiller wrote: post #28
mulmen wrote: 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…

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…

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

Later model physical DEC terminals had a mode called PCTERM (with escape sequences to enter/exit it) in which the terminal would send PC keyboard scan codes for key presses. However, very few terminal emulators implement that.

The Telnet server and client in Windows NT implements a somewhat similar feature, the VTNT terminal type, in which keyboard scan codes and mouse movements are transmitted in a binary format which is based on the Windows console API. (Nowadays Telnet is mostly deprecated in favour of SSH; there is no reason why SSH clients and servers could not implement VTNT, but I haven't seen any do it.)

The technology already exists to solve this problem, and has for years. It is just that nobody appears to care about it enough for that technology to become widely adopted.

Re: Colorize Your CLI

#78

Post by spc476 »

craftkiller wrote: post #28
mulmen wrote: 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…

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…

For issue #3, it would have been nice had the TTY layer sent DLE ESC when someone hits the ESC key. As it is now, once you read the ESC key, you have to wait some number of milliseconds to see if more data is coming in, and if not, then just return a single key, else it's an escape sequence. Sigh.

Re: Colorize Your CLI

#79

Post by O_H_E »

Tade0 wrote: post #30

Somewhat related: My friend is developing a colour palette based on Solarized: https://github.com/jan-warchol/selenized but with more perceptual uniformity.

Looks really nice . Thanks for sharing

Re: Colorize Your CLI

#80

Post by O_H_E »

danyspin97 wrote: post #16
monokh wrote: post #11

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.

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.

> treat

*threat

Post reply on HN