On 10/05/2022 15:21, Pádraig Brady wrote:
> On 10/05/2022 09:45, Mikael Magnusson wrote:
>> Hi,
>>
>> In bug #9086 [1] there was a lot of good discussion about case
>> insensitive matching for dircolors. This was all then summarily
>> ignored in [2] which made the behaviour unconditional. This breaks
>> coloring of uppercase files that should have a different color from
>> lowercase files, for example .C which is a c++ source file, not a c
>> source file. And as mentioned in [1] it is also very useful to notice
>> incorrectly (eg uppercase extension files) quickly by them being
>> white, so you can fix them.
>>
>> I'm not sure if the suggestion in this bug (33123) is good though;
>> since ls --color=auto-case will just error on older releases, you
>> can't easily sync your aliases. Unfortunately ls also ignores all of
>> LS_COLORS if it contains any unknown values (why??) so we can't add a
>> "CS" field there for case sensitiveness either (unless there's some
>> extra options field already I don't know about?).
>>
>> If anyone has some ideas I would be happy to produce a patch (assuming
>> you don't need copyright assignment).
>>
>> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9086
>> [2] https://lists.gnu.org/archive/html/coreutils/2018-06/msg00011.html
> 
> Thanks for taking the time to tie all these threads together.
> 
> Yes we forgot about [1] when implementing [2].
> 
> The ideas in [1] are sound. I.e. we shouldn't need a new option.
> We just need to honor any capitalized extension entries,
> and fall back to case insensitive for lower case extensions.
> We do need to be cognizant of performance though.
> We could sort the list of extensions, which would auto give
> precedence to capitalized entries, and we might also use that
> sorting to break out of the match loop early.

The attached will honor different sequences defined for
separate extension letter cases, by operating case sensitively
for those extensions.

cheers,
Pádraig