The version hasn't been updated in forever either. Fix that and then figure out some way to automate it since I am not going to remember

I'm using Ubuntu under WSL2 and zsh. Here's what one of my dirs looks like w/ this LS_COLORS:

And when I comment out . "/home/mpen/.local/share/lscolors.sh":

I thought it was supposed to color different file types differently?

$ diff -Nur .dircolors <(wget -o /dev/null -qO- https://raw.githubusercontent.com/trapd00r/LS_COLORS/master/LS_COLORS) | wc -l
0

$ grep -E '^..+' .dircolors | awk '{print $1}' | sort | uniq -D
.asc
.asc
.dmg
.dmg
.enc
.enc
.eps
.eps
.jsm
.jsm
.midi
.midi
.pod
.pod
.ps
.ps
.sig
.sig
.t
.t

Hello, thanks for the nice work!
I can't make LS_COLORS work on a ksh terminal. I have downloaded LS_COLORS and added the eval command to my .kshrc but nothing happens.

Could you help?
Thanks!

https://github.com/ogham/exa

Lines 928-929 show .scm as a GIMP project file. A GIMP project file is actually .xcf; .scm is the extension for the "scheme" scripting language which is commonly used to write GIMP filters. I don't know that .scm is exclusive to GIMP, though.

If you are interested, here are a few more GIMP extensions;
.gpl - palette
.pat - pattern
.gtp - tool preset
.ggr - gradient
.gdyn - brush dynamic

grep -P is an experimental feature and is not available on some platforms, easy patch will be something like perl -ne 'if (/^[\.\*]([A-z0-9]+)/) { print $1; }'

It seems like LS_COLORS is optimized for a dark background.

It would be nice to have a light variant.

See e.g. http://github.com/seebi/dircolors-solarized for a similar project with different variants.

Right now SETGID has a background color (albeit hard to notice on black bg) while SETUID doesn't. In any case, SETUID should be much more obvious than anything else.

Yellow/red background like the default DIR_COLORS use might not be too bad. Maybe darker but an "alarmy" color would be a good idea.

Trying to use LS_COLORS in OS X (Note, it's LSCOLORS in OS X, not LS_COLORS).

eval $(dircolors -b ~/.LS_COLORS/LS_COLORS)
export LSCOLORS=$LS_COLORS

But, I get:

$ ls
error: invalid character '=' in LSCOLORS env var
warn: LSCOLORS should use characters a-h instead of 0-9 (see the manual page)
error: invalid character '8' in LSCOLORS env var
error: invalid character ';' in LSCOLORS env var
error: invalid character ';' in LSCOLORS env var
error: invalid character '8' in LSCOLORS env var
error: invalid character ':' in LSCOLORS env var
error: invalid character '=' in LSCOLORS env var
error: invalid character '8' in LSCOLORS env var
error: invalid character ';' in LSCOLORS env var
error: invalid character ';' in LSCOLORS env var
error: invalid character ':' in LSCOLORS env var

Any ideas?

In #83 we discovered that MS Office documents are rendering with underline style in some terminals. This doesn't make a lot of sense to me. Look into that and consider something else. Also investigate if other document types are also using underline, bold, or italic styles inappropriately.

Referenced in #48

Hey,

you might readd the screenshot.

Cya,

Sigi

I'd rather have an explicit close for every open fold marker. Right now it's
pretty random where any fold is explicity closed or not.

Indentation of the comments is also pretty out of whack. Sometimes a thing is indented,
sometimes not. Probably the thing to do is just kill all the indendtation. Idk.

I recognize that probably 99% of people out there aren't using these, but I am,
so I'll get around to this eventually.

e.g. terraform etc.

BSD ls is extremely limited and doesn't even support coloring by extension. Furthermore the format they use is no where near that of GNU ls.

@jmcantrell suggested that the best approach would be to simply install GNU ls.
Another solution might be to use https://github.com/trapd00r/ls-- which can perform colorization on files matching arbitary patterns.

Feel free to reopen this issue if you have any feedback.

I am using the Windows Subsystem for Linux (WSL). I followed the setup instructions.

Here is my LS_COLORS:

But the correct colors do not show up for the file extension when I am viewing that are available where Windows is mounted:

The colors are displaying fine as long as I am not in the /mnt folder or any of its subdirectories:

Any ideas what could be going wrong?

Here is the relevant portion of my .bashrc:

UPDATE: I think the issue is with the files being executable:

Could someone please explain what is going on here?

Thanks!

Hey Magnus

Great stuff your LS_COLORS. Thanks a ton.
If you ever find time, maybe you could also add file extension for tcpdump:

*.pcap
*.cap
*.dmp

Cheers,
Stefan

Coloring ls output looks great. Thanks for putting this together.

Am unable to make it work however.
Using Mac - 10.14.2.
Fish shell - fish, version 3.0.0

carried out this command.
wget https://raw.github.com/trapd00r/LS_COLORS/master/LS_COLORS -O $HOME/.dircolors

then added
eval ( dircolors --c-shell $HOME/LS_COLORS ) to config.fish in ~/.config/fish

but receiving this error

eval ( dircolors --c-shell $HOME/LS_COLORS )
fish: Unknown command 'dircolors'
fish:
 dircolors --c-shell $HOME/LS_COLORS
 ^
in command substitution
	called on standard input

I looked up solutions to this but none seems to work.

1. Tried brew install coreutils per recommendation here #3

Tried to run gls after installing coreutils but no glorious colors :(

2. Changed the command to refer to $HOME/.dircolors

eval ( dircolors --c-shell $HOME/.dircolors )
fish: Unknown command 'dircolors'
fish:
 dircolors --c-shell $HOME/.dircolors
 ^
in command substitution
	called on standard input

Any suggestions? Thank you!

I have a heavily modified version of LS_COLORS from this repo and I have eval "$(dircolors $HOME/.config/LS_COLORS)" in ~/.profile to ensure it LS_COLORS gets generated once. problem with this is that whenever I make changes, I have to logout for them to take effect or eval dircolors in .zshrc (which would defeat the purpose).

What does this zplugin plugin do exactly? does it load LS_COLORS from this repo, or can take a modified one? does it update whenever this repo updates or whenever LS_COLORS gets updated?

zplugin ice atclone"dircolors -b LS_COLORS > c.zsh" atpull'%atclone' pick"c.zsh"
zplugin load trapd00r/LS_COLORS

Hello, I noticed a wrong behavior in the colorized output of tree (it didn't reset the boldness after a bold line, e.g. executable files), so writing to the author of the program he pointed me to my LS_COLORS varaible.
So, in order to fix this I commented the NORMAL line in the LS_COLORS file (it's used by tree to reset the line, boldness included).
I don't know if this can cause worst thing to happen.
Here a screenshot of a zsh session replicating the issue (without LS_COLORS, with LS_COLORS, and commenting out the NORMAL line):
http://i.imgur.com/FhXad.png

• Manifest.in
• Pipfile
• Pipfile.lock
• requirements.txt

maybe others

I've added eval $(dircolors -b path/to/LS_COLORS) to my .bashrc file and everything worked. On the next reboot, GNOME Display Manager started but I was not able to log-in. Removing the eval makes Gnome grat again. journalctl show this:

Process 1994 (gnome-session-b) of user 1000 dumped core.                         
Stack trace of thread 1994:                                                      
#0  0x00007fb1d3a37a04 match (libpcre.so.1)                                      
...                                                                              
#63 0x00007fb1d3a4665e match (libpcre.so.1)                                      
                                                                                 
Stack trace of thread 2141:                                                      
#0  0x00007fb1d3c84a6f __poll (libc.so.6)                                        
#1  0x00007fb1d3f0e80e g_main_context_iterate.isra.0 (libglib-2.0.so.0)          
#2  0x00007fb1d3f0eb93 g_main_loop_run (libglib-2.0.so.0)                        
#3  0x00007fb1d415da4a gdbus_shared_thread_func (libgio-2.0.so.0)                
#4  0x00007fb1d3f37fc2 g_thread_proxy (libglib-2.0.so.0)                         
#5  0x00007fb1d3aaa4e2 start_thread (libpthread.so.0)                            
#6  0x00007fb1d3c8f6d3 __clone (libc.so.6)                                       
                                                                                 
Stack trace of thread 2140:                                                      
#0  0x00007fb1d3c84a6f __poll (libc.so.6)                                        
#1  0x00007fb1d3f0e80e g_main_context_iterate.isra.0 (libglib-2.0.so.0)          
#2  0x00007fb1d3f0e943 g_main_context_iteration (libglib-2.0.so.0)               
#3  0x00007fb1d3f0e991 glib_worker_main (libglib-2.0.so.0)                       
#4  0x00007fb1d3f37fc2 g_thread_proxy (libglib-2.0.so.0)                         
#5  0x00007fb1d3aaa4e2 start_thread (libpthread.so.0)                            
#6  0x00007fb1d3c8f6d3 __clone (libc.so.6) 

Gnome bug? Any clues? Have you ever encountered this?

I'm using GNU ls, and the first color definition (from dircolors) works...

*.mp3=00;36

Whereas this one (from this repo) does not...

*.mp3=38;5;191

*.bib files are similar to plaintext databases that store bibliography entries. (examples). It is mostly frequently used with *.tex files. However, I'm not sure what color to use with it. Can anyone make a PR for this? Thank you!

zsh --version: 5.7
and I also use it in deepin-terminal
This doesn't. All files are in the same color.

followed the instructions for bash on my OSX terminal and when source .bash_profile was ran it gave me the following output. I have my bash_profile and bashrc to sync together so i know the eval function was placed in bashrc but there shouldn't be an issue when it comes to it being in bash_profile or bashrc.
If anyone has an idea on how to fix this I would greatly appreciate it

An installation script is provided with this repository:
$ wget https://raw.github.com/trapd00r/LS_COLORS/master/LS_COLORS -O /tmp/LS_COLORS
$ ( cd /tmp/LS_COLORS && sh /tmp/LS_COLORS/install.sh )

Problem:
cd: not a directory: /tmp/LS_COLORS
because wget downloads a file.

The project's front page (readme) looks like this to me now:

Here is the direct link. I get a 404.

Can you set different color for these extension? i don't know how to change it in my hand:

*.bam
*.bai
*.vcf
*.bed
*.R
*.RData

thanks.

This is less of a bug and more of a question, but what do the color definitions in LSCOLORS represent? If i were to take a color from that file, let's say
.wv 38;5;136;1

It's obviously not rgba. How do i translate that to hex or rgba? Googling for it doesn't give me anything to go on,

I'm trying to convert a vim theme to my lscolors file.

Thank you

I just started using your LS_COLORS for my terminal. The colors look nice, but I don't understand why some file types are shown in bold font while others aren't. Maybe there's some pattern behind it, but I don't see it.

Furthermore, subdirectories are often hard to spot as they get drowned out by the various types of files.

Have you considered using bold text for directories and regular text for everything else? I think that would be clean and consistent.

Should be some kind of metadata, but maybe not in the existing metadata group

Edit: This was originally about .vcf and .vcard extensions but it sprawled into something much more ambitious.

The install instructions say

wget https://raw.github.com/trapd00r/LS_COLORS/master/LS_COLORS -O $HOME/.dircolors
echo 'eval $(dircolors -b $HOME/.dircolors)' >> $HOME/.bashrc
. $HOME/.bashrc

Which is correct (it works). But the instruction above them says to add

eval $( dircolors -b $HOME/LS_COLORS )

to the .bashrc, Which doesn't work, unless of course you pair it with

wget https://raw.github.com/trapd00r/LS_COLORS/master/LS_COLORS -O $HOME/LS_COLORS

given a file path, rseturn the color codes for the type
given a file path, return the colored string

return all colors code for all types

In the README.md there is this screenshot:

From the readme it's not clear how can you apply colours to the permissions-part of ls command.

Could you clarify how you did it?

With the list of supported extensions growing, two problems are growing harder to ignore:

1. Collisions. We're literally running out of space for new colors, unless we start using more background colors (which are ugly and, imo, should be reserved for files that need to be shouted about).
2. Stylistic consistency. I can find several things to be concerned about here, but this will only get worse as more filetypes are supported. To illustrate my point, a few quick examples that need work:

• We use 38;5;166 for the following filetypes: all files with the executable bit, m2v (video), odp (spreadsheet).
• We use a rainbow of colors for image, video, audio file formats, emulator savegames and roms, etc: but it is not clear why the variety within each domain is needed (or even helpful). Consolidation would help with quickly and intuitively identifying "what kind of stuff is in here", and help with avoiding collisions.
• We use 38;5;41 for .py files but also .fcm (an audio format) and a bunch of archive formats.

Would you like a pull request with attempts at addressing this problem?

Just a heads up - we can no longer match uppercase and lowercase extensions differently, like so:

.pl 38;5;197
.PL 38;5;32

because of: coreutils/coreutils#14

We can however match the entire filename like so:

*Makefile.PL 38;5;32

with the commit 1c9dfd7#diff-1e41905d9f35a0e2aa259dc7735cf497
the .Z extension was removed for some reason. The standard 'compress' utility adds by default .Z extension. Why was it removed?

Can you explain how to get this nice mod-time feature (43 sec, 4 min, …) ?

All the colors looked great up until the recent change to the dircolors format. I have some colors, but they look nothing like the screenshot on the main page.

Given an extension, or name.extension, return the color codes only

On any project I maintain I like to document the license to keep everything legally sound. Since you are the copyright holder, what license would you release this under? GPL2/3? MIT? Public domain? Let me know and I'll add the appropriate LICENSE file and disclaimers.

After i done this:

wget https://raw.github.com/trapd00r/LS_COLORS/master/LS_COLORS -O $HOME/.dircolors
echo 'eval $(dircolors -b $HOME/.dircolors)' >> $HOME/.bashrc

in my HOME dir added .dircolors file, and to my .bashrc addedeval $(dircolors -b $HOME/.dircolors) line.
But the . $HOME/.bashrc not actually work, it is say bash: .: //.bashrc: is a directory, why is that so?
But if i navigate to HOME using cd $HOME and then . .bashrc it does as must.
But colors did not changed, i tried with ls, dir, du none displays other colors, except dir --color=auto which as i think uses own colors, i mean not related to .dircolors.

How to make it work?

AFAICT symlinks are coloured according to the extension of the link:

This makes it difficult to tell from a simple ls whether a file is a symlink, whereas it's a different color in standard color schemes.

What would be ideal would be a format that preserved the color of the extension while adding something else (e.g. underline, inverted colors, or italics, preferably not italics as it doesn't work on many terminals). I understand that may be difficult as underline is already used for .docm .pptxm .pptsm .xlsxm .xltm and LS_COLORS, but it'd make a big difference (at least for me).

LS_COLORS output:

gls and ls output on macOS:

Orphan links are already highlighted, which is great.

Sorry if this has come up before, couldn't find an issue that mentioned it.

I was able to get this working on a Mac by using gls (GNU ls) instead and just then compiling the repo using dircolors in a quick Ubuntu docker.

I think it could be nice to add these instructions/functionality to the repo and for example compile LS_COLORS automatically by default on each commit.

@rpdelaney what do you think? Would you approve if I created a Pull request for it? I didn't see anything on the docs about your thoughts on Mac support