#479544 dircolors: please eliminate duplicates before writing variable

Package:
coreutils
Source:
coreutils
Description:
GNU core utilities
Submitter:
martin f krafft
Date:
2022-06-21 14:45:04 UTC
Severity:
wishlist
#479544#3
Date:
2008-05-05 12:21:22 UTC
From:
To:
If I specify a filetype twice in the dircolors file, the resulting
LS_COLORS will have the entry twice:

  lapse:/% echo "EXEC 00\nEXEC 01" | dircolors -
  LS_COLORS='ex=00:ex=01:';
  export LS_COLORS

While /bin/ls works fine with it and prefers the last setting over
previous ones, e.g. zsh's completion system works the other way.

I realise I could be filing this as a bug against zsh, but that
would be asking zsh to work around a shortcoming in the dircolors
"API".

Instead, would it be possible to fix dircolors so that it eliminates
earlier entries if the dircolors file overrides entries for a given
file class?

The rationale is that I need dircolors --print-database output in my
own dircolors file if I don't want to hardcode defaults by hand. If
I do that, I'd prefer to keep customisation separate.
#479544#8
Date:
2008-05-05 17:29:27 UTC
From:
To:
martin f krafft <madduck@debian.org> wrote:

Good idea.
If no one volunteers to do this soon
I'll put it on the TODO list.
#479544#11
Date:
2008-05-06 08:30:43 UTC
From:
To:
also sprach Jim Meyering <jim@meyering.net> [2008.05.05.1829 +0100]:

FWIW, this is a zsh-style way of dealing with it. It's not exactly
rocket science, I just use an associative array to uniquify:

http://git.madduck.net/v/etc/zsh.git?a=blob;f=.zsh/zshrc/89_dircolors;hb=HEAD
#479544#16
Date:
2008-05-06 08:46:37 UTC
From:
To:
martin f krafft <madduck@debian.org> wrote:

Yep.  When this is done in dircolors, it'll do the same, using lib/hash.c.
#479544#21
Date:
2022-03-15 18:21:35 UTC
From:
To:
#479544#26
Date:
2022-06-21 14:36:04 UTC
From:
To: