GNU bug report logs - #33123
ls: add case-sensitive --color option

Previous Next

To reply to this bug, email your comments to 33123 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Matt Martini <matt.martini <at> imaginarywave.com>
To: bug-coreutils <at> gnu.org
Cc: kaxandra.labat <at> gmail.com
Subject: non-backwards compatible change to ls
Date: Mon, 22 Oct 2018 23:42:54 -0400

[Message part 1 (text/plain, inline)]

There was a change in the behavior of ls that is unconditional (no
way to revert to the old behavior) and incompatible with the
previous behavior.

The change is listed in the Changelog for 8.30:

2018-06-20  Kaxandra Labat  <kaxandra.labat <at> gmail.com>
 ls: ignore case when coloring file extensions
   * src/ls.c (get_color_indicator): s/STREQ_LEN/c_strncasecmp/
   * src/dircolors.hin: Remove a now redundant entry.
   * tests/ls/color-ext.sh: Add a new test.
   * tests/local.mk: Reference the new test.
   * NEWS: Mention the change in behavior.

This breaks the use case where different colors are assigned to suffixes
whose case is different. The old behavior allowed for making visually
distinct different cased suffixes.

For example:

    image.jpg    could be rendered in green
    image.JPG    could be rendered in green with a yellow background 

This would allow for easy identification of non-uniform cases,
especially in directories with large numbers of files.

What I am requesting is a way to get the old behavior back. 

One suggestion would be adding a setting to the —color option, whereby

    --color=auto				would turn on colorization case-insensitive (as the new behavior works)
    --color=auto-case		would turn on colorization case-sensitive (as the old behavior worked)

Thank you.

Matt

[Message part 2 (text/html, inline)]

Message #14 received at 33123 <at> debbugs.gnu.org (full text, mbox):

From: Mikael Magnusson <mikachu <at> gmail.com>
To: 33123 <at> debbugs.gnu.org
Cc: Eric Blake <eblake <at> redhat.com>
Subject: ls: add case-sensitive --color option
Date: Tue, 10 May 2022 10:45:37 +0200

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

-- 
Mikael Magnusson

Message #17 received at 33123 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Mikael Magnusson <mikachu <at> gmail.com>, 33123 <at> debbugs.gnu.org
Subject: Re: bug#33123: ls: add case-sensitive --color option
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

Message #20 received at 33123 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Mikael Magnusson <mikachu <at> gmail.com>, 33123 <at> debbugs.gnu.org
Subject: [PATCH] ls: --color: honor separate sequences for extension cases
Date: Sun, 4 Sep 2022 20:23:30 +0100

[Message part 1 (text/plain, inline)]

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

[ls-honor-color-cases.patch (text/x-patch, attachment)]

Message #23 received at 33123 <at> debbugs.gnu.org (full text, mbox):

From: Matt Martini <matt.martini <at> imaginarywave.com>
To: 33123 <at> debbugs.gnu.org
Subject: Re: bug#33123: ls: add case-sensitive --color option
Date: Sat, 28 Jan 2023 14:31:30 -0500

[Message part 1 (text/plain, inline)]

Pádraig
Thanks for the patch.

Are there any plans to have this patch folded into coreutils?

What is the process to make that happen?  Is there anything I could do to help?

Matt

[signature.asc (application/pgp-signature, attachment)]

Message #26 received at 33123 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Matt Martini <matt.martini <at> imaginarywave.com>, 33123 <at> debbugs.gnu.org
Subject: Re: bug#33123: ls: add case-sensitive --color option
Date: Sat, 28 Jan 2023 20:24:12 +0000

On 28/01/2023 19:31, Matt Martini wrote:
> Pádraig
> Thanks for the patch.
> 
> Are there any plans to have this patch folded into coreutils?
> 
> What is the process to make that happen?  Is there anything I could do to help?

I'm working on an improved version
as my proposed one is a bit inefficient.
I hope to have this completed quite soon,
and to be included in the next coreutils release soon after that.

cheers,
Pádraig

Message #29 received at 33123 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Matt Martini <matt.martini <at> imaginarywave.com>, 33123 <at> debbugs.gnu.org
Subject: Re: bug#33123: ls: add case-sensitive --color option
Date: Mon, 13 Mar 2023 15:30:25 +0000

On 28/01/2023 20:24, Pádraig Brady wrote:
> On 28/01/2023 19:31, Matt Martini wrote:
>> Pádraig
>> Thanks for the patch.
>>
>> Are there any plans to have this patch folded into coreutils?
>>
>> What is the process to make that happen?  Is there anything I could do to help?
> 
> I'm working on an improved version
> as my proposed one is a bit inefficient.
> I hope to have this completed quite soon,
> and to be included in the next coreutils release soon after that.

The current version should be good enough for this release,
and I'll improve after if needs be.

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.