Re: vtty & X terminal color scourge

[davidson <davidson@freevolt.org>]

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