[ On Thursday, April 22, 1999 at 05:51:57 (-0400), Dave Cinege wrote: ]
> Subject: Re: (a)sh command line editting and history patch.
>
> Curt Sampson said:
> > 
> > Someone (Dave Cinege, I think) said:
> > > 
> > > Several hundred KB of space, as well as not a seemless part of the shell.
> >[[....]]
> > And what makes this more `seamless'?
> 
> It's part of the binary. (???)

I'm still not sure I understand this 'seamless' part.  Libedit can
certainly be statically linked right into the sh binary (and it's
possible that it'll not all be linked in then either -- I've never tried
this to see).

While libedit is not really small, it's not all that big either, given
the functionality it provides:

text    data    bss     dec     hex
61440   8192    0       69632   11000   obj.i386/libedit.so.1.0
-rwxr-xr-x  1 root  wheel  70195 Jan 13 22:24 obj.i386/libedit.so.1.0

I can't imagine that any really portable and terminal independent
command-line editing could be much smaller than this either, at least
not unless you get rid of either one mode or another (i.e. pick one:
emacs or vi).  Without seeing your implementation I can only guess that
it's hard-coded to the most minimal ANSI support offered by the PC
console driver, and using not much more than the cursor keys.  While
this might be useful for *some* very limited embedded systems, I'm not
sure it's worth maintaining in the common (a)sh source.  What might make
sense is implementing a really cut down version of libedit that is
suitable for such applications (i.e. provide the same API but skip some
of the functionality) -- then the size savings would come for free with
every utility that uses libedit.

However I'll second Matthias Buelow's recommendation to use pdksh
instead of (a)sh (which eliminates the choice of using libedit's API
since PD KSH doesn't use libedit).  This is from PD KSH v5.2.13.7
99/01/15 with both editing modes compiled in, on NetBSD-1.3I/i386 (with
/bin/sh for comparison):

text    data    bss     dec     hex
282592  8192    8964    299748  492e4   /bin/sh		# static
274400  4096    10180   288676  467a4   ksh.static
163808  4096    4272    172176  2a090   ksh.shared

Without vi-mode editing and without job control, it shrinks quite a bit:

./configure --disable-vi --disable-jobs
text    data    bss     dec     hex     filename
258016  4096    5748    267860  41654   ksh.static
143328  4096    0       147424  23fe0   ksh.shared

A wee big more code disappears if you compile it as sh (which eliminates
all command-line editing and history, as well as a few ksh features like
[[ ..]], select, let, brace-expansion, extended globing, co-processes,
special environment variables, and so on):

./configure --enable-shell=sh --disable-jobs
text    data    bss     dec     hex     filename
229344  4096    5360    238800  3a4d0   sh.static
114656  4096    0       118752  1cfe0   sh.shared

A significant part of the savings in ksh's size over (a)sh is, I think,
from its own private command-line editing support which seems to be
significantly smaller than libedit:

text    data    bss     dec     hex
4656    0       16      4672    1240    edit.o
10792   16      200     11008   2b00    emacs.o
4912    8       24      4944    1350    history.o
14184   40      4360    18584   4898    vi.o

You might even be able to convince the PD KSH maintainer to add your
editing mode as a third run-time and compile-time option.

Certainly command-line editing can bloat a *lot* bigger!  ;-)

text    data    bss     dec     hex
24576   4096    0       28672   7000    libhistory.so.2.2
110592  16384   0       126976  1f000   libreadline.so.2.2

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>