After updating world terminal color support stopped working. Reproducible: Always Steps to Reproduce: 1. Create "~/.dir_colors" and "/etc/DIR_COLORS" containing only comments (e.g. default one). 2. Start new instance of bash shell. Actual Results: Default bash prompt is not colored. Expected Results: Default bash prompt should be colored. I.e. green for user and red for root. /etc/bash/bashrc - lines 45-50: Bash retrieves supportable color terminals list from "~/.dir_colors" and "/etc/DIR_COLORS". If files do not exist then it retrieves it from "dircolors --print-database". If files exist but contain nothing except comments (e.g. default DIR_COLORS) then bash ends up with empty list unable to match any available TERM value.
What do you propose exactly here? Ok, maybe you have a little point, but why /etc/DIR_COLORS would be empty? It's part of coreutils, and default bashrc uses it.
(In reply to comment #1) > What do you propose exactly here? Ok, maybe you have a little point, but why > /etc/DIR_COLORS would be empty? It's part of coreutils, and default bashrc uses > it. > As I see the problem: 1. Bash has to recognize color terminals. 2. To perform this it needs to retrieve a supportable terminals list. 3. There are two ways of doing that: a. Parse DIR_COLORS -> get system list. b. Use bash database in case of exception -> get default list. I do not think that the empty system list is a correct value. Empty system list is the same thing in nature as the absence of it and should be processed the same way i.e. by using the default list. Why would DIR_COLORS be empty? I do not know. This is just an exceptional situation that is not processed by bashrc or processed incorrectly. I think that in my case coreutils simply replaced it with an empty file after updating world.
the *default* prompt relies on the dircolors database. if you break the dircolors database, then you need to declare your own prompt if you want colors.
