Just one user's random input:

Those expert users building minimal NetBSD systems can trim out such a
simple editor.  Suppose that a system configuration flag (set once) lets
you enable/disable including the editor when you build a custom
configuration?  Then you needn't deal with it through upgrades, but those
that want it can have it.  Would that be feasible and would it make
everyone happy on that point?

Second, editor size: A 20K statically editor would be unacceptably large
in my eyes, for no more than has been proposed.  (Let's assume a stripped
binary, since naive users aren't likely to be debugging it.  The resource
usage of the editor should be simple, so if the standard C library has
grown too bloated, the editor can rely exclusively on kernel calls.)  If
the editor assumes VT100 type support, etc., then how can it possibly take
100K to do edit/move/search/save/exit?

Third, it was once pointed out that one reason that we don't have BASH as
our sh replacement is because it is normally dynamically linked.  This in
turn would be a problem if you needed your shell up and running (or shell
scripts) at a time when /usr isn't available.  By a similar token, it
seems undesirable if this editor should not be available just because /usr
isn't available.  That pretty well rules out putting it in /usr/bin, and
also rules out using shared libraries.

Fourth, I reflect on the goals of NetBSD.  One of the chief ones is Doing
It Right.  I'm not sure that a stripped down editor is doing anything
right.  What if the hypothetical naive user/admin needs to use a serial
console which doesn't happen to support VT100?  Saying ``that won't happen
very often'' sounds a lot like the reported LINUX folks' views about
fsync() (see -advocacy and port-i386, I believe).  The editor should WORK.  
Unfortunately, this means something along the lines of termcap (a lot of
bloat suddenly invades, though it may not be too bad).  That might be the
end of it, but the whole idea just doesn't sit well with me, as I think
about it.

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


I do have a proposal, however.  Instead of a new editor, I propose a shell
script, called ``help''.  help would contain some ``user-bootstrapping''
information, including (at the tail end) a note that you can use ``help |
more'' to page through the help file, AND that if you are in an editor
such as ed, you can invoke help by using ``!help'' or ``!help | more''.  
(These last points should be quite prominant.)

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.

Net change to the system: A simple script (implemented with a ``here
file'', I would guess) to dump some user-bootstrapping info.  Ideally, it
should all fit on a typical ~80x~25 display (say 72x20 if possible).  It
won't take the place of man pages, and shouldn't try to.  But it should
tell the user about some important concepts and tools (more, ed, man, cat,
ls, apropos, stty; caveats about single-user/multi-user and maybe even how
to manually mount a filesystem---plus how to get back to the help file
(paging if necessary) from command-line programs.).

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

Thoughts?


  "I probably don't know what I'm talking about."  --rkr@rkr.kcnet.com