LS_COLORS
LS_COLORS copied to clipboard
multiple definitions
$ 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
Thank you. I'm vaguely aware of this problem but haven't got around to looking into it. I wonder how many of the duplicates are in the "undefined" section at the bottom. Perhaps we should get rid of that.
Ideally this would be tested by some kind of CI system so we would know if a PR introduces dupes.
do you mean 'unsorted' ? Anyway, all current duplicates are listed in my first comment. In the oneliner to find all duplicates above the escape in the grep's regex was eaten though. The dot after ^ should be escaped
vifm
has a utility that helps with this called vifm-convert-dircolors
:
$ vifm-convert-dircolors LS_COLORS > lscolors.vifm
Different attributes for extension in different cases: \.pl at /usr/local/bin/vifm-convert-dircolors line 216, <DIRCOLORS> line 191.
Different attributes for extension in different cases: \.eps at /usr/local/bin/vifm-convert-dircolors line 216, <DIRCOLORS> line 381.
Different attributes for extension in different cases: \.ps at /usr/local/bin/vifm-convert-dircolors line 216, <DIRCOLORS> line 384.
Different attributes for extension in different cases: \.midi at /usr/local/bin/vifm-convert-dircolors line 216, <DIRCOLORS> line 445.
Different attributes for extension in different cases: \.dmg at /usr/local/bin/vifm-convert-dircolors line 216, <DIRCOLORS> line 510.
Different attributes for extension in different cases: \.pod at /usr/local/bin/vifm-convert-dircolors line 216, <DIRCOLORS> line 668.
Different attributes for extension in different cases: \.t at /usr/local/bin/vifm-convert-dircolors line 216, <DIRCOLORS> line 702.
Argument "target" isn't numeric in numeric eq (==) at /usr/local/bin/vifm-convert-dircolors line 321.
The ones missing from vifm's list are because the definitions aren't different. They're just repeated. I'll remove those.
As for the others:
Suggested conflict resolutions:
Extension | Groups | Resolution |
---|---|---|
.ps | vector, words | words |
.eps | vector, words | words |
.midi | audio, lossless | lossless |
.dmg | apps, images | apps |
.pod | markup, unsorted | markup |
.t | perl(?), unsorted | remove |
Edit: I'm also moving .epsf
into words
.pl
and .PL
have different colors for mysterious reasons. I'm not a perl guy but some person in #perl
on freenode says
a file called Something.PL in a dist directory is expected to be run sometime during the dist build process to generate a file called Something.
They also told me that perl uses .t
by default for tests.
This exposes the need for better persistent documentation of wtf these filenames are.
@trapd00r I vaguely remember us talking about you building some wild database for extensions, did you make any progress with htat?
.pl
and.PL
have different colors for mysterious reasons. I'm not a perl guy but some person in#perl
on freenode saysa file called Something.PL in a dist directory is expected to be run sometime during the dist build process to generate a file called Something.
Yes, .PL is colored the same as a Makefile with no extension because it's almost always 'Makefile.PL'.
They also told me that perl uses
.t
by default for tests.
Correct.
@trapd00r I vaguely remember us talking about you building some wild database for extensions, did you make any progress with htat?
Well, we made this: https://github.com/trapd00r/LS_COLORS/issues/112#issuecomment-447568557 and blew up our environment in the process. Haven't tested the last comment in that thread.