> >And what's wrong with that?  A shared library implementing a common
> >command line interface with command history, Emacs or vi editing,
> >completion "and all that jazz" wouldn't add much of a load, and would
> >make the whole environment more comfortable to use.
> 
> Not much, except that not all ports have shared libraries.

(1) that could be considered a bug.

(2) If you're worried about inefficiency on those machines, there are
more interesting things to look at.  For instance, on the Alpha:

-r--r--r--  1 bin  bin  2019668 Nov 27 01:49 /usr/lib/libc.a
-r--r--r--  1 bin  bin   225196 Nov 27 01:50 /usr/lib/libedit.a

(both have the standard set of symbols that a library would have.)

fcsk_ffs(8) compiled with -DSMALL (which has the sole interesting
effect of removing one call to getpwuid()) is (stripped):

-rwxr-xr-x  1 cgd  wheel  204800 Dec 10 17:29 obj/fsck_ffs*

but compiled without -DSMALL is (again, stripped):

-rwxr-xr-x  1 cgd  wheel  360448 Dec 10 17:29 obj/fsck_ffs*


Indeed, a C program which consists only of a call to getpwuid() ends
up being (again, stripped):

-rwxr-xr-x  1 cgd  wheel  229376 Dec 10 17:28 a.out*


When (yp + rpc + db) are used by so many things, and are so huge, it's
not clear that worrying about the size of libedit is worthwhile.




chris