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
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.
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 ].
I do most of my stuff through Emacs' own facilities and don't use the shell that often, and every now and then knowing me some Bourne shell proves useful, so I stick to it, I completely forget otherwise.
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. :)
alias ls="ls -GF"
export LSCOLORS="Exfxcxdxbxegedabagacad"
-G Enables colorized output
-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.
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:
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'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?
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:
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'
which also displays `/` at the end of dirs, `*` for executables and so on.
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.
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.
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
> 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.
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.
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.
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