Live data from Hacker News

Colorize Your CLI

danyspin97.org

11–20 of 124 posts

Re: Colorize Your CLI

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

Re: Colorize Your CLI

#12
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).

Re: Colorize Your CLI

#13
post #9
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…

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.

Re: Colorize Your CLI

#14

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…

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

Re: Colorize Your CLI

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

http://blog.z3bra.org/2014/01/images-in-terminal.html

https://askubuntu.com/questions/97542/how-do-i-make-my-termi...

Re: Colorize Your CLI

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

Re: Colorize Your CLI

#17

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…

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

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.

Re: Colorize Your CLI

#18
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…

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.

Re: Colorize Your CLI

#19
post #9
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…

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

Re: Colorize Your CLI

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

Post reply on HN