On Wed, 5 Apr 2023 at 02:47, Greg Wooledge <g...@wooledge.org> wrote:
> On Tue, Apr 04, 2023 at 10:33:26PM -0400, Felix Miata wrote:
> > What bothers me more than anything is that dead symlinks haven't been red,
> > or
> > anything else to distinguish them, in a long time.
> So... you're talking about the colors used by "ls", yes?
>
> If you don't want ls colors at all, you can use "ls --color=never".
> You can set that up as an alias/function.
>
> If you DO want colors, just not the ones you're currently getting, then
> you need to look at the LS_COLORS environment variable.
>
> According to ls(1), you're supposed to use dircolors(1) to generate
> this variable. According to dircolors(1), you're supposed to run
> "dircolors --print-database" and read its output to learn how to set
> it up.
According to adduser(1):
adduser will copy files from SKEL into the home directory
According to adduser.conf(5):
SKEL is the directory from which skeletal user configuration files are copied.
Defaults to /etc/skel
/etc/skel/.bashrc contains:
# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" ||
eval "$(dircolors -b)"
The output of 'dircolors -b' looks like:
LS_COLORS='<preconfigured_values>'; export LS_COLORS
The above is how Debian sets up the default value of LS_COLORS.
The values in use, if any, can be seen by
echo $LS_COLORS
Personally I dislike the preconfigured values because they try
to color the output according to BOTH the type of file AND the
filename suffix, which creates a mess. Because the coloring
depends on whether or not the filename is matched.
I create a simpler ~/.dircolors which detects only the type of the file,
and use the above method to control the colors shown by 'ls'. I find it is
very useful for recognising hardlinks as well as good or bad symlinks
in the output of 'ls' command. It's not hard and gives a useful result.
I also configure 'mc' to use the same colors.
