Subject: Re: RFC simple screen editor for NetBSD
To: Richard Rauch <firstname.lastname@example.org>
From: Aaron J. Grier <email@example.com>
Date: 01/08/2000 10:59:16
posted back to netbsd-advocacy -- It seems more appropriate than
On Sat, Jan 08, 2000 at 09:31:02AM -0600, Richard Rauch wrote:
> Fourth, I reflect on the goals of NetBSD. One of the chief ones is Doing
> It Right.
> I like the idea of helping people try to get started. I just increasingly
> don't care for the notion of a stripped-down editor. Easy-to-use, after
> all, doesn't have to mean under-powered...
> Wait, did I mention ed?
> Yes. ed. It's not glitzy. It feels a little primitive, BUT: It's
> quite simple to learn how to use; it really is a serious and important
> tool; it works under a truly broad range of environments; it's already
> in the system. I propose that, in addition to a ``help'' command, new
> users be directed to using ed.
Ed is the mother of all editors... I learned a bastard hack of ed under
RSTS/E in high school, and after traveling through jove, microemacs,
emacs, pico, vi and ended up with vim, and my ed knowledge has become
once again extremely useful. vim == vi improved, vi == visual ed. Ed
is much more terse than vi, but works more places.
In my experience, ed is a good editor to teach beginners. A single
sheet (or help screen) can explain how to turn on the prompt and line
numbers, insert and delete text, save and quit. As a bonus, ed makes
minimal assumptions about the install environment, and is already in
I've always felt that the NetBSD Project is not about providing a
sugar-coated unix to the masses, (NeXT / Apple do a fantastic job at
that,) but about providing a svelte, consistent, and multiplatform
integrated unix environment without the bullsh*t (for the most part)
badly-implemented multiple layers of indirection between the user and
One solution to the editor conundrum is making / adapting a small fast
and tight editor to fit within the NetBSD philosophy, but I'd argue that
an even better solution would be more quality documentation. Un*x in
general has always had rather terse documentation, which makes perfect
sense if you already know the lingo, but is almost impossible to
bootstrap from unless you have a mind of stone. Even my favorite unix
book, _The UN*X Programming Environment,_ assumes that you already have
a working system you can play around on.
If the issue is having a usable editor in which to edit startup scripts,
wouldn't an addition to sysinst make the most sense?
> Perhaps a seperate file (or another script?) could be written to give
> a brief overview of using ed (this in case the man pages aren't up for
> some reason and the user _needs_ to edit a file).
I think we need a supplement to the INSTALL document which has a sysinst
walkthrough, along with either an ed introduction, or a way to toggle
settings in rc.conf inetd.conf (along with documentation on what all the
options are) as well as adding a "normal peon" user account for the
fledgling sysadmin to learn unix on without worrying about deleting
important files, and the like. Remember, this is just a novice
bootstrap method -- not a be-all-end-all solution.
Aaron J. Grier | "Not your ordinary poofy goof." | firstname.lastname@example.org
"Time Correct function allows automatically correcting slight variation
of your key touching manner." -- Roland MSQ-700 manual