Colorls – A Ruby script that beautifies the terminal's ls command(github.com)
github.com
Colorls – A Ruby script that beautifies the terminal's ls command
https://github.com/athityakumar/colorls
44 comments
Acknowledged. The executable has been renamed to `colorls`, which can optionally be aliased in the shell configuration file. :-)
colorls is already in use, at least on OpenBSD it's a package that provides colorized output for ls (though not to the extent of this effort).
This is perfect for someone like my who's entire terminal existence is comprise of avoiding user the Finder as much as humanly possible.
Another solution to the problem of coloring `ls` output is to use the `dircolors` command, which configures the colors `ls` uses in it's output. Piggybacking on `ls` has other benefits: if you change `ls` colors, it'll get picked up by other programs, for example zsh auto-complete and the `tree` command, among others.
For those interested, there are pre-existing dircolors config files that people have shared, like dircolors-solarized[1].
Of course, the OP's program does more than just ls, in that it has icons and a `--report` flag.
[1]: https://github.com/seebi/dircolors-solarized
For those interested, there are pre-existing dircolors config files that people have shared, like dircolors-solarized[1].
Of course, the OP's program does more than just ls, in that it has icons and a `--report` flag.
[1]: https://github.com/seebi/dircolors-solarized
Oh my god colours. I'm an emacs user who uses shell mostly in shell-mode (i.e. a dumb shell, no curses), and dealing with these colourful commands is so annoying. Developers, please check what $TERM is like, and if it's "dumb", don't print coloured output. Main offenders for me: Ruby stuff, the new apt(8) on Ubuntu.
That aside, this is not my cup of tea (I prefer dired, and don't mind the lack of icons, tho they might've been a nice ornament), but yet it looks nice, kudos. But colour me not if [ x$TERM = xdumb ].
That aside, this is not my cup of tea (I prefer dired, and don't mind the lack of icons, tho they might've been a nice ornament), but yet it looks nice, kudos. But colour me not if [ x$TERM = xdumb ].
Better yet, use the proper terminfo-aware routines for printing colors instead of just emitting raw ANSI escapes.
I've been accustomed to using trapd00r's LS_COLORS[1]. It differentiates the colors by file types enough to make it useful, without being overly distracting. And doesn't require installing ruby. :)
[1] https://github.com/trapd00r/LS_COLORS
[1] https://github.com/trapd00r/LS_COLORS
On macOS I have this in my .profile:
-F Display a slash (`/') immediately after each pathname that is a directory, an asterisk (`*') after each that is executable, an at sign (`@') after each symbolic link, an equals sign (`=') after each socket, a percent sign (`%') after each whiteout, and a vertical bar (`|') after each that is a FIFO.
The filename/dirname is colored and the character denoting the type is not colored, so I can tell what is part of a name and what denotes the file type.
alias ls="ls -GF"
export LSCOLORS="Exfxcxdxbxegedabagacad"
-F Display a slash (`/') immediately after each pathname that is a directory, an asterisk (`*') after each that is executable, an at sign (`@') after each symbolic link, an equals sign (`=') after each socket, a percent sign (`%') after each whiteout, and a vertical bar (`|') after each that is a FIFO.
The filename/dirname is colored and the character denoting the type is not colored, so I can tell what is part of a name and what denotes the file type.
Thanks! This is great, works with oh-my-zsh
I've been using https://the.exa.website/ and it works fairly decently. Does the same coloring and tells you git status. Doesn't do icons though.
Of course someone links to exa right as I accidentally upload a broken linux version... of course!
I don't understand the very tricked out shells people have. Surely all those colours and bits of information are just noise that distracts over a longer shell session?
I tend to feel the same way but then again I have a fair amount of information that can show up in my prompt, the difference however being that it is all black against a black background so the only time I see it is if I highlight a line. Works out well for having an information dense prompt but keeping the distractions and noise lower.
I absolutely love having a colourful shell -- assuming that each program doesn’t end up competing for your attention! I’m far more likely to notice an error if it’s red, or a warning if it’s yellow, as I find out about them subconsciously without having to read each line. However, if every program has a different idea of what an “error” is, then I’m just going to start ignoring red lines instead.
I agree with you. I set my $PS1 to just show the folder and the exit status of the previous command. I set the dirtrim to 2 so it looks something like this in action:
0[~/.../a/folder]$ false
1[~/.../a/folder]$
PROMPT_DIRTRIM=2
PS1='\[\e]2;[\W]\$\a\]$(printf "%d" $?)[\w]\$ 'There are lots of folks here for which the shell interface is usefull, but difficult to use. Using colors and graphics can be super helpful for folks with dyslexia, along with asymmetric fonts (thing I learned this year: comic sans scores incredibly well as a font for people with dyslexia). So don't poke fun.
I don't have that problem, but I don't see any problem including redundancy. I have come to like Powerline-hs's git support because even if I only half-glimpse a window I immediately know the status of the repo from it just by the colors. I don't see why I wouldn't want to maximize the channels of information coming back to me.
I don't have that problem, but I don't see any problem including redundancy. I have come to like Powerline-hs's git support because even if I only half-glimpse a window I immediately know the status of the repo from it just by the colors. I don't see why I wouldn't want to maximize the channels of information coming back to me.
I'm not arguing for a monochrome shell with no information; my current prompt is:
[user@hostname:path](git branch)$
There are colours highlighting these sections. What I'm referring to is the multi-line prompts with dates, times, uptimes etc that surely just clutter up the history view?
[user@hostname:path](git branch)$
There are colours highlighting these sections. What I'm referring to is the multi-line prompts with dates, times, uptimes etc that surely just clutter up the history view?
Ew way too much noise for my liking. Having said that I did use k[1] in the past. I prefer a more minimal setup these days.
https://github.com/supercrabtree/k
https://github.com/supercrabtree/k
It looks like this uses the github logo for the .git folder. Why not the git-scm logo?
https://git-scm.com/images/[email protected]
https://git-scm.com/images/[email protected]
![https://git-scm.com/images/[email protected]](https://git-scm.com/images/logo@2x.png){kind=link}
Sadly, the font icon seems too tiny when used on the terminal. Only the GitHub logo seems easily viewable.
Feel free to share your thoughts here : https://github.com/athityakumar/colorls/issues/33
Feel free to share your thoughts here : https://github.com/athityakumar/colorls/issues/33
ls -G
will get you colors in macOS. I'm sure a lot of people will like the icons but they're not for me. Around last year I got burned out on things nagging for my attention by bouncing, booping, turning red, popping up a pretty picture. Turning off all notifications on my phone was a good first step.
おまけ：
Here is the "ultimate" OSX ls that I found on the internet some time ago:
alias l="ls -aeGhlO@"
Of course that is too much information sometimes, so I kept a vanilla ls too:
alias ls="ls -aG"
will get you colors in macOS. I'm sure a lot of people will like the icons but they're not for me. Around last year I got burned out on things nagging for my attention by bouncing, booping, turning red, popping up a pretty picture. Turning off all notifications on my phone was a good first step.
おまけ：
Here is the "ultimate" OSX ls that I found on the internet some time ago:
alias l="ls -aeGhlO@"
Of course that is too much information sometimes, so I kept a vanilla ls too:
alias ls="ls -aG"
With ls from GNU coreutils (ie. on Linux) you can get colored output with `--color=auto`. An alias for `ls` with this option is frequently already there in the systemwide .bashrc or equivalent. Personally, I use something like this:
alias ls='/bin/ls -hlFA --color=auto'
GNU/Linux
You know, I could have written something like "On Linux you can get colored output from `ls` command ..." etc. without ever mentioning GNU at all. I went out of my way to say "GNU coreutils" (also because it's possible to install these tools on Mac and other *nixes) and you're still unsatisfied? Sorry, but that looks like you're being overly pedantic for no good reason.
> おまけ：
Me speaka the 和語 too, but no need to show off. Just say "bonus:", it's an english language site.
That said, thanks for the tips!
Me speaka the 和語 too, but no need to show off. Just say "bonus:", it's an english language site.
That said, thanks for the tips!
If you like this, check out even-better-ls[0]. It does pretty much the same thing but does it just by setting LS_COLORS, so no need to run a separate script. I also find the spacing it uses much nicer.
[0] https://github.com/illinoisjackson/even-better-ls
[0] https://github.com/illinoisjackson/even-better-ls
Slightly off topic but: I was trying to figure out how he got a github icon in there then found out it uses: https://github.com/ryanoasis/nerd-fonts
Very cool. Definitely using this for some of my CLI tools.
Very cool. Definitely using this for some of my CLI tools.
Interesting use of icons.
Personally I find many different colors confusing. I've a wrapper script that highlights permissions etc. rather than using colors to distinguish them. It also makes the output of ls consistent across linux/osx/solaris/... which it does by adjusting the output from the existing ls implementations on each platform
http://www.pixelbeat.org/scripts/l
Personally I find many different colors confusing. I've a wrapper script that highlights permissions etc. rather than using colors to distinguish them. It also makes the output of ls consistent across linux/osx/solaris/... which it does by adjusting the output from the existing ls implementations on each platform
http://www.pixelbeat.org/scripts/l
In the demo, is that a Powerline status, solarized palette?
Let's check the first paragraph of the readme…
> Here are the screenshots of working example on an iTerm2 terminal (Mac OS), oh-my-zsh with powerlevel9k theme and powerline nerd-font + awesome-config font with the Solarized Dark color theme.
> Here are the screenshots of working example on an iTerm2 terminal (Mac OS), oh-my-zsh with powerlevel9k theme and powerline nerd-font + awesome-config font with the Solarized Dark color theme.
Beautiful!!!
Good work, OP.
What is the speed like? Ruby isn't exactly known for being the fastest.
Since you're presumably intending to at least glance at all the output, it's hard to imagine speed being a limiting factor here.
Also internal bookkeeping done by the terminal is probably going to limit how much command speed matter, e.g. word/line wrapping: https://stackoverflow.com/questions/21947452/why-is-printing...
Also internal bookkeeping done by the terminal is probably going to limit how much command speed matter, e.g. word/line wrapping: https://stackoverflow.com/questions/21947452/why-is-printing...
That is kinda true... but I did notice that once you have a few of such extensions, terminal can get perceivably laggy and slow. If the tools startup / load time is slow, it can make command-line feel unresponsive.
disclaimer: I'm not using the fonts, but it attempts to render them anyway.
Here's what `time ls` and `time lc` produced, in a directory with 517 files:
> ls --color=tty -l 0.01s user 0.00s system 93% cpu 0.007 total
> ~/.gem/ruby/2.4.0/bin/lc 0.14s user 0.01s system 98% cpu 0.159 total
It's definitely noticeable, especially if you use `ls` day-in, day-out. But it's nothing debilitating.
Here's what `time ls` and `time lc` produced, in a directory with 517 files:
> ls --color=tty -l 0.01s user 0.00s system 93% cpu 0.007 total
> ~/.gem/ruby/2.4.0/bin/lc 0.14s user 0.01s system 98% cpu 0.159 total
It's definitely noticeable, especially if you use `ls` day-in, day-out. But it's nothing debilitating.
Probably it could be made faster by working a little with InstructionSequence https://ruby-doc.org/core-2.4.1/RubyVM/InstructionSequence.h... and creating a "compiled" file to save the parsing time.
I played with it on the day they released Ruby 2.3. It's not meant for distributing code across machines and it could fail on the same machine after some updates. It's probably not worth it to shave 152 ms on an interactive command.
I played with it on the day they released Ruby 2.3. It's not meant for distributing code across machines and it could fail on the same machine after some updates. It's probably not worth it to shave 152 ms on an interactive command.
The fonts don't seem to matter. This thing is super cool but I disagree that it's not debilitating. `ls` on my home directory takes 0.005 real, `colorls` takes 0.554 real. Over 100x as long and it's an extremely noticeable half second.
If powerline doesn't slow people down, I'm pretty sure the 10ms Ruby invocation time is equally fine.
But as someone who lives in the terminal, it's not something I would use at all. To me, the fancy fontawesome glyphs PLUS the colors are information overload [1]. It really feels like overkill. I'm not trying to discourage anyone (including the author) from writing these things, and clearly the author is a very good programmer.
If it was an exercise in making something beautiful in the terminal, then the author succeeded in this endeavor. Making a good looking, consistent terminal UI is ridiculously difficult, and each column is pretty and formatted. This program feels like it has had a lot of TLC. Honestly, I hope the author continues to make cool programs in the terminal; they clearly have a knack for it :)
As a minor aside, maybe consider changing the executable name from `lc` to something else; it conflicts with the `lc` executable for Mono (at least on Arch[2], and Ubuntu[3]). But that's just a minor nitpick.
[1] this is my opinion, I want to make this as clear as possible
[2] https://www.archlinux.org/packages/extra/i686/mono/files/
[3] http://manpages.ubuntu.com/manpages/trusty/man1/lc.1.html