Re: colorls in base

[Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>]

At 15:02 Uhr +0000 16.02.2019, Christos Zoulas wrote:
>Yes, what I don't understand (because nobody has stated a technical
>reason other than 'fluff'),

... I guess that hurt. It wasn't meant to, sorry, just a tongue-in-cheek
handle to a serious point.

> why we shouldn't we have the feature in base at all.

I remember you speaking up against replacing csh(1) with tcsh in base a few
years ago. How about adding tcsh's complete facility to csh(1)? That is
probably an order of magnitude in codesize compared to ls(1) vs.
colo(u)rls, but I see a moral equivalent.

>Things change over time; we don't go rip out color output compiler
>support from the compilers. It is not enabled by default so it is
>invisible.

We don't, because needless deviating from upstream source incurs high
maintenance cost, and is frowned upon.

>So will be having color in some programs in base. It will
>be invisible unless you specifically turn it on.

I guess some of us see a slippery slope?

>It is not frictionless (and should be but that's another issue) to
>"install from pkgsrc" and it's a good question why not have the feature
>in base when the majority of the users just install replacements from
>pkgsrc because of the lack of features.

Careful, that way lie bash and emacs, cups and ...

> It is not 1980 anymore and
>we don't need to be frugal about resources (specially when they can
>be compiled out).

Well, we still support most of the architectures we supported in the
mid-nineties (and even vax from the eighties). So it would be nice if base
ran reasonably well on them.

Cheerio,
hauke


--
"It's never straight up and down"     (DEVO)