On Feb 17, 12:30am, Robert Elz wrote:
}
} Date: Sat, 16 Feb 2019 15:02:58 -0000 (UTC)
} From: chris...@astron.com (Christos Zoulas)
} Message-ID: <q498n2$3f0j$1...@blaine.gmane.org>
}
} 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
