Re: colorls in base

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 16 Feb 2019 15:02:58 -0000 (UTC)
    From:        christos%astron.com@localhost (Christos Zoulas)
    Message-ID:  <q498n2$3f0j$1%blaine.gmane.org@localhost>

  | Yes, what I don't understand (because nobody has stated a technical
  | reason other than 'fluff'), why we shouldn't we have the feature in base
  | at all. Nobody proposed to enable it by default.

They haven't yet, but eventually will.   Sometime, if this was added,
someone will say "Why don't we enable colours from ls by default, just
like all the other OS's do?  We have the code already, all we need to do
is turn it on."   That's almost guarranteed to happen.

If you (and everyone else, including the THF board, and core) will agree
that as soon as someone suggests this, that colour support would
immediately be removed from ls again, then I would have less problems
with it...

Personally, I don't see any big difference between "install from pkgsrc"
(for a simple program, as distinct from some part of one of the monsters)
compared with doing some configuration setup - in fact, for naive users,
one could say that installing from pkgsrc is likely to be easier,
particularly as they're going to be doing it for all kinds of other
things as well (unless we start shipping all kinds of other stuff,
browsers (a choice thereof) PDF viewers (same) image viewers (same)
video players (same) ...)

Note that whatever one might think, a simple "-X turns on colours" is
not going to work.   Something has to determine which colours get used,
and that cannot really be a constant, as what works depends upon the
user's terminal foreground and background colours, and, at least as much
as I know about this stuff, there's no reasonable way for a program like
ls to discover what those are.   That is, if ls decides that directories
should be blue (which I think someone said that some colourising version
of ls does) how does that work in a terminal with a blue background?

Doing this properly is not at all easy.  Doing it poorly is not something
we ought to be aiming for,

Personally, I believe that we ought to keep base to the basic set of
programs that are needed to be able to use the system well enough to
be able to install more, and not attempt to provide everything that
anyone might ever want - and particularly not because some other OS
does it that way.   Being different can be a good thing - particularly
when it is leaner and cleaner.

A while ago in this "conversation" maya posted a liet of things that
get replaced as part of the install -- that list only had one thing
in common with me, the window manager.   And while twm certainly isn't
what almost anyone would pick, it still functions, and is enough to
allow X to be used while installing something better.   And of course
this is a case where there's zero chance we'd ever come close to
agreeing on what particular better replacement to include.

What I do replace from base (every time) is postfix (by sendmail).
Somehow I doubt that a request to stick sendmail back in base is
going to get very far.

The lesson from this, I think, is that different users have different
needs and desires, and we cannot possibly meet all of them, and it would
be unreasonable to pick some particular (especially controversial)
functionality and add it, while not adding everything that everyone else
wants as well.

  | As features become standard to other OS's we should evaluate if
  | we should follow suit.

That's reaosnable.   But "XYZ has it, so so should we" or "XYZ has it
and I like it" are not reasons - what we need to discover is what we
are missing (what we cannot achieve) without it. or what is much
harder.   If something adds some ability that is either lacking, or
very difficuly to achieve any other way, then sure, we should add it.
If all it would achieve is making NetBSD look the same as XYZ, then
we should not.

  | Things change over time; we don't go rip out color output compiler
  | support from the compilers.

Had I known it was there I might have.   What a truly brain dead idea.

It truly shocked me to read the "it enables eye balling to quickly find
the error message" - has no-one ever learned anything?  We have (nicely
powerful) searching abilities that can do that much better, in much bigger
output, much more quickly, and almost infinitely mroe accurately, than
any form of human eye-balling will ever achieve, whatever assistance is
added.   Doing anything to make eye-balling to find stuff (whatever it
might be) is pushing things in entirely the wrong direction.   If anything
we should be making that harder, not easier, top encourage proper use
of the tools (and yes, even in a browser, you can search for text!)

  | "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.

If we could demonstrate that for something in particular, then that
might be a convincing argument.   But I very much doubt that is true
for coloured ls output.   More often, this seems to be more "I install
xxx, so surely everyone else does as well, so it should be in base".
I doubt we have any idea how many people install anything in particular.

kre

ps: Also in this discussion there has been menytion of "ls -F".   I had
always assumed that we had that utter crud only because POSIX says that
it is required, I never imagined that anyone would actually use that
nonsense.  Eg:

	jinx$ ls -F
	x*  y*

What do you deduce from that?   If you thing there are two files, x and
y, and they're both executable, then, sorry, you're wrong.   But even
with that knowledge, what do you know now?   Anything at all?   I very
much doubt it (except that there are two files in '.').   The only part
of ls -F that works, is the '/' to indicate directories, but that's
not needed, as "ls -d */." or just "echo */." work to tell you what
sub-dirs exist in the current directory (and do it better).

Whever designed that option (the way that it works) is a cretin.

The way to find out what kind of things exist in a directory is to use
ls -l and look at the mode bits, or use stat - or write a simple script
to use one of those (or find) to extract whatever info you actually need,
which will almost certainly be different than what I need.  It has been
that way since the early Bell Labs versions, and nothing anyone has ever
done t attempt to make it better, or easier (in any environment) has
achieved either of those goals, as best I can tell.   Nothing.

kre