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

101–110 of 124 posts

Re: Colorize Your CLI

#101

Post by 1_player »

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.

starship looks good on paper, but the fact that all plugins are by default enabled (from what I can tell from the docs) is a no-go for me.

Why do people need all that information on their prompt? I understand showing the git status, but is it really necessary to know that your battery is discharging and you're currently using node v10.12.3 and elm v1.2.3 every single time you run a command in some directory?

Re: Colorize Your CLI

#102

Post by necrotic_comp »

eddieh wrote: post #83
necrotic_comp wrote: post #62

Earlier quoted context omitted.

If you do work on a number of different machines, in production and in dev, knowing what host you're on, what directory you're in, etc. helps avoid errors like killing a process in prod when you thought you were in dev. While writing code, it's helpful to know what branch you're on with git, so you don't accidentally commit code to the wrong branch, etc. I typically have something like 30-40 terminals open at a time,…

I have ssh sessions to remote machines, I use multiple terminal windows, and multiple tabs. I don’t use tmux, is there something about tmux that makes it hard to know where you are?

There's nothing specific about tmux that makes it hard to know where you are, but it does let you keep any number of terminals open on one screen, which is super-helpful, but requires a lot of mental overhead to keep track of where everything is.

If you're able to keep track of the context of 50 windows without a prompt, more power to you, but that's not something I can do and I require some signage to ground where a specific prompt is.

Re: Colorize Your CLI

#103

Post by hhas01 »

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…

The technical problem is you can’t effect worthwhile improvements in the terminal without also fixing the fundamental flaws below it: a huge mess of bloated, inconsistent, poorly-introspectable command executables, with only untagged, untyped “dumb” pipes to connect them together in the most laborious, unsafe way possible.

The logistical problem is, well… see all the other comments from those who don’t want it to change, whether through laziness, apathy, turf protection, or whatever. Next to the People Problem, the technical problem is the easy part to solve.

Incidentally, here’s what a good 1980s CLI looks like:

https://www.youtube.com/watch?v=o4-YnLpLgtk

Whereas the nix craphouse we’re now stuck with isn’t even a good 1970s* CLI.

Honestly, at this point I wouldn’t even bother trying incremental improvement. The *nix CLI does what it was built to do, and that’s all. When substantive change does come to text UIs it will be as revolution, not evolution.

Draw a line under it. Learn its lessons, both the DOs and DON’Ts. Then whiteboard from the ground-up what needs to come next. Work out where UI/UX needs to be in 2040 to effectively serve the billions of users of the generations to come, and make a start on building that. Dash ahead of history for a change, not be shackled and dragged back by it.

As old, traditional divisions between text, voice, and touch interaction become increasingly frustrating impediments in modern mass-market devices, there’s a killing to be made in smashing down all those old artificial barriers and replacing them all a single unified interaction model that can transition seamlessly between all three modes as its users’ needs and wishes direct.

Re: Colorize Your CLI

#104

Post by zvr »

eddieh wrote: post #51

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

It all depends on your mode of working. You want to have information showing the current state of stuff that changes.

If you only work as the same user, having $USER in the prompt is visual clutter, and you very soon learn to ignore it -- then why have it? If you only work as one user or "root", you can encode this difference in the "$"/"#" character.

Current directory... is very useful. I have worked for years without it (before it was available) and it really made a difference. Yes, it just saves you a command (pwd, dirs, ...), but it's nice to have this info right there.

Where I would agree is the git branch info. How do people use it in their prompt? This is filesystem-level data, totally independent from the current shell session. To give an example: I have two terms (shells) and in both I am in ~/mydir. They both show got branch "master". In one of them I change to another branch. That window's shell prompt gets updated but the other windows still shows me as being in "master". Do people press enter before each command to have the prompt updated to actual values?

Re: Colorize Your CLI

#105

Post by IggleSniggle »

Morgangeek wrote: post #95
IggleSniggle wrote: post #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…

I've also aliased cat to bat but it causes me issues when I redirect the output of cat (bat) without \cat to a file as then the file contains color codes that are not expected by other users and tools and cause some tools to not behave correctly,while the issue is invisible to me (unless reading the generated file with \cat)

bat should not be doing that. It should perform exactly like cat when piped or redirected. At least it does for me, even if the text is colorized in a tty. Perhaps an issue with your pager settings? Dunno.

Re: Colorize Your CLI

#106

Post by IggleSniggle »

samsaga2 wrote: post #31

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.

To my brain, syntax coloring makes recognizing the shape of some code a more rapid/fluid process. It also provides a nice feedback loop for potential typos (in my cli setup, a misspelled command will be red instead of green, a string will be yellow, etc) so that you can catch an error before you execute/commit.

Outside of all of that, I enjoy the rainbow festival aesthetic. I coded a lot as a kid for fun, and was good at it, but got away from it as an adult. I think a huge part of transforming back into an enthusiast was all the attention to themes, fonts, ligatures, autocompletions, etc. I really enjoy "talking" with my computer, and all of the styling gives a sort of pseudo-personality, as the computer responds to my syntax with different colors as I'm writing it.

That said, you might not like rainbow personalities! That seems to make you an outlier, but it doesn't matter! One great thing about code is that it can be easily adapted to a users preferences...that is, as long as you're using tabs for indentation and spaces for alignment ;-)

Re: Colorize Your CLI

#107

Post by basilisks »

smabie wrote: post #70
enriquto wrote: post #55

Earlier quoted context omitted.

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.

You're telling me that you don't use colors with ls? This isn't even a matter of debate, ls with colors is superior and more efficient.

`ls -F` is good enough for me

Re: Colorize Your CLI

#108

Post by dleslie »

a1369209993 wrote: post #94
dleslie wrote: post #93

Earlier quoted context omitted.

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.

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

Re: Colorize Your CLI

#109

Post by always_left »

ausjke wrote: post #38

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)

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.

Re: Colorize Your CLI

#110

Post by diego898 »

IggleSniggle wrote: post #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…

Thanks for the links! Could you say a bit more about how you use/configure fzf to work in combination with bat and delta?
Post reply on HN