On Tue, 4 Apr 2023 Greg Wooledge 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.
[trimmed interesting stuff about dircolors]
My reading of the OP is that his ls output is not colorised, and he
probably does *not* want to hand-roll some custom color semantics. He
just wants to enable the behavior he remembers.
This section of /etc/skel/.bashrc is pertinent, I think:
# 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)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'
#alias grep='grep --color=auto'
#alias fgrep='fgrep --color=auto'
#alias egrep='egrep --color=auto'
fi
I would expect that the alias above for ls (and uncommenting the
aliases for dir, vdir) in one's ~/.bashrc ought to be sufficient to
colorise its output as OP remembers.
In my own accounts' ~/.bashrc, I comment out the ls alias above,
because I do *not* want ls to semantically colorise its output. Having
done that, I have never needed the --color=never alias (in my
accounts).
--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin
