GNU bug report logs - #9086
'dircolors' request: support UPPERCASE suffixes, also, please.

Previous Next

Full log

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 9086 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>,
	marcel partap <mpartap <at> gmx.net>
Subject: Re: bug#9086: ls --color: 30% speed-up and case-insensitive suffixes
	[Re: bug#9086
Date: Tue, 09 Oct 2012 15:18:56 +0100

On 10/09/2012 02:32 PM, Jim Meyering wrote:
> Pádraig Brady wrote:
>> On 10/09/2012 01:32 PM, Jim Meyering wrote:
>>> Pádraig Brady wrote:
> ...
>>>> So do we now only support suffixes delimited by '.' ?
>>>> Previously the delimiter was arbitrary or optional:
>>>>
>>>>     touch star; LS_COLORS="*tar=01;31" /bin/ls --color *tar
>>>
>>> Good catch.  I realized that early on, but then forgot to mention it.
>>> Yes, I would have to document that the "." is now required.
>>> It seems like a reasonable restriction, but technically
>>> it could be called a regression.
>>>
>>> Also, with these changes, a multiple-"." suffix will no longer work.
>>> I.e., before, if you wanted to give *.tar.xz files a color different
>>> from plain *.xz files, you could.
>>>
>>> Does anyone object to that?
>>
>> It's marginal, though I'd be inclined to keep the existing
>> support for arbitrary suffixes. We could fall back to the
>> slower linear scan iff an entension entry in LS_COLORS didn't
>> contain a single '.'  To be more generally performant and
>> support a longest suffix match we'd have to use something
>> like a trie I think.
>
> Well, I confess that I am not inclined to spend more time on this,
> and don't think the dot-less or longest-suffix use cases are worth the
> added code (we were already using most of hash.c already, so my change
> induced almost no bloat), so I'm tempted to go ahead with the patch and
> wait for complaints before adding trie-based lookup.

Sure. I wasn't really suggesting we do trie now,
just mentioning that would be a possible route in future.

As for enabling the faster and slightly more limited code for now...
It's a hard decision. I suppose it's OK for now but it'll need a
change in behavior note in NEWS.

cheers,
Pádraig.

Previous Next

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