export LS_COLORS : apply the rule for every file beginning by README*

Question

I have a problem with the following rule. If I do:

eval `/opt/local/libexec/gnubin/dircolors ~/.dircolors`
export LS_COLORS="${LS_COLORS}*README=00;37;44"

Then, when creating a README file, then I will get:

But now, I would like to apply the rule and do the same for every filename beginning by README (like README_something, README_important).

for this, I tried to put:

 export LS_COLORS="${LS_COLORS}*README*=00;37;44"

but it is not displayed as above image (only white).

How to manage the wildcards with LS_COLORS (I am on MacOS Big Sur)?

Edit 1

Following user1934428's advice, I tried with:

export LS_COLORS="${LS_COLORS}:*README*=00;37;44"

Unfortunately, for example, a filename like README_important doesn't display like my image above when I apply the command "l" which is actually defined by:

alias l='grc -es --colour=auto ls --color -Gh -C -lrt'

Why isn't the syntax README accepted ? especially, the second star which is supposed to expand all the files named like README_something, README_anything... etc

Edit 2

Here is the value $LS_COLORS, once I open a new terminal:

$ echo $LS_COLORS
no=01;37:fi=01;37:di=32:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:ex=00;36:*~=05;31:*.mtxt=05;31:*.ndx=05;31:*.cmd=00;33:*.exe=00;33:*.com=00;33:*.btm=00;33:*.bat=00;33:*.txt=00;37:*.pdf=04;94:*.docx=00;91:*.doc=00;91:*.xlsx=00;91:*.xls=00;91:*.c=00;35:*.h=00;35:*.sh=00;36:*.py=00;36:*.cpp=00;35:*.pl=00;36:*.pm=00;35:*.cgi=00;35:*.java=00;35:*.html=00;35:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.jpg=01;35:*.jpeg=01;35:*.JPG=01;35:*.gif=01;35:*.GIF=01;35:*.bmp=01;35:*.BMP=01;35:*.xbm=01;35:*.ppm=01;35:*.xpm=01;35:*.tif=01;35:*.png=01;35:*README*=00;37;44

I have now only one ':' character.

But this doesn't solve the original issue, i.e the taking into account of the wildcard for README* filenames.

Answer 1

I see several problems here:

You obvously assume that LS_COLOURS already has a value, because you expand it. However, entries in LS_COLOURS are separated by a colon, and you don't have one.

The other problem is that sequence matters: ls parses the entries one after the other, as soon as it finds a matching one, this is the colour it uses. Therefore, more specific entries should be at the start of the colour list.

UPDATE

I tried out various variations with my version of ls(GNU coreutils 8.26) and found that a wildcard pattern such as *README* would be ignored. The only kind of wildcard pattern is an asterisk at the start of the entry. Hence,

LS_COLORS='*README-txt=35;46'  /bin/ls --color=yes *README*

colorizes my file x-README-txt, but

LS_COLORS='*README*=35;46'  /bin/ls --color=yes *README*
LS_COLORS='*READ*-txt=35;46'  /bin/ls --color=yes *README*

don't. Also, my above remark about the sequence of entries was not correct. While sequence indeed does matter, entries further to the right take priority. Therefore, if you have

LS_COLORS='*txt=35,46:*t=32,44'  /bin/ls --color=yes *README*

the file x-README-txt would be colorized using 32,44.

Answer 2

I would like to apply the rule and do the same for every filename beginning by README (like README_something, README_important).

That is not possible. Looking at the sources of GNU ls https://github.com/wertarbyte/coreutils/blob/master/src/ls.c#L4206 the filename is matched form the end until it matches the string with strncmp.

Also this handles empty LS_COLORS:

export LS_COLORS="*README=00;37;44${LS_COLORS:+:${LS_COLORS}}"