Subject: Re: bug#33123: ls: add case-sensitive --color option

From: Pádraig Brady <[email-masked]>
Date: Tue, 10 May 2022 15:21:37 +0100

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.

I'll look at this soon.

cheers,
Pádraig