LS_COLORS icon indicating copy to clipboard operation
LS_COLORS copied to clipboard

multiple definitions

Open flux242 opened this issue 5 years ago • 8 comments

$ 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

flux242 avatar May 03 '19 12:05 flux242

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.

rpdelaney avatar May 03 '19 15:05 rpdelaney

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

flux242 avatar May 03 '19 16:05 flux242

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.

rpdelaney avatar Aug 12 '19 20:08 rpdelaney

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

rpdelaney avatar Aug 12 '19 20:08 rpdelaney

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

rpdelaney avatar Aug 12 '19 20:08 rpdelaney

@trapd00r I vaguely remember us talking about you building some wild database for extensions, did you make any progress with htat?

rpdelaney avatar Aug 13 '19 15:08 rpdelaney

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

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 avatar May 23 '21 12:05 trapd00r

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

trapd00r avatar May 23 '21 12:05 trapd00r