Re: colorls in base

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Feb 17, 12:30am, Robert Elz wrote:
}
}     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>
} 
} 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.

     I would support it.  :-)  But, I agree with you that it would
be pretty pointless to make the proposal.  You would get a crap
ton of people jumping up and down, screaming stuff about security,
even with:

i386devel: {169} cvs up pkg-vulnerabilities
M pkg-vulnerabilities   (the local mods are all related to Asterisk)
i386devel: {170} grep -ic sendmail pkg-vulnerabilities
15
i386devel: {171} grep -ic postfix pkg-vulnerabilities
18

Some will argue about ease of configuration and this can certainly
be a valid argument.  I've been configuring sendmail since the late
'80s, i.e.  before the M4 days.  I also make extensive use of
milters.  With postfix, I know enough to get it to forward to a
smart mailer, which will be sendmail.  I don't know how to configure
it to do the stuff that I do with sendmail.  However, I do recogonise
that having a simple well commented config file will be easier for
most people, especially those that don't have highly complex special
situations.

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

     +1

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

     Wow!  Quite the rant.  I use ls -F all the time and find it
to be very useful.  I've been using it since I first touched a
unix-like system somewhere in the late '80s.  The alternatives that
you mention certainly work, but are more cumbersome.  I agree that
they may be needed in some situations as they are more "authoritative".
After all, there is nothing stopping somebody from naming a regular
file "x*", which would be quite annoying, since the only characters
that can't appear in a file name are "/" and "(null)".

     What is interesting about this rant is that many people use
colorls to do what "ls -F" does (i.e. distinguish regular files
from directories and executables).  This means that your rant mostly
applies to colorls as well, except that colorls won't mix up regular
file "x*" with executable file "x".  However, since I don't know
what the different colours mean (and they would disappear if I send
the output to a pipe/file) they convey absolutely no useful
information to me (and likely many others not coming from a certain
environment).

     On a side note, I once had an issue with a "/" appearing in
a filename.  It was on a system that acted as an NFS server to
Macs.  MacOS used ":" as the directory separator so "/" was allowed.
This was obviously a bug in the NFS server software.  I ended up
using cleari followed by fsck to get rid of that nasty little thing.
It was probably the only time that I used cleari.

}-- End of excerpt from Robert Elz