Date: Sun, 20 Jun 2010 02:08:57 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: Stefan Farfeleder <stefan@fafoe.narf.at> Cc: Jilles Tjoelker <jilles@stack.nl>, freebsd-arch@freebsd.org Subject: Re: Further sh(1) plans Message-ID: <AANLkTin4Dpspkud2GnYLfZyo33L9uwr9u2_UMRYi_jvE@mail.gmail.com> In-Reply-To: <20100620090019.GA1731@mole.fafoe.narf.at> References: <20100619113126.GB83874@stack.nl> <20100620090019.GA1731@mole.fafoe.narf.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 20, 2010 at 2:00 AM, Stefan Farfeleder <stefan@fafoe.narf.at> wrote:
> On Sat, Jun 19, 2010 at 01:31:26PM +0200, Jilles Tjoelker wrote:
>>
>> For embedded systems, it may be best to disable libedit entirely in the
>> end product (we don't currently have a knob for this). If you need to
>> log in to such a system, the additions will likely be useful, as there
>> may not be any other shell on the system. The completion code is fairly
>> small compared to the rest of libedit.
>
> Maybe we could compile two sh binaries, an interactive one with all the
> fancy features enabled (filename completion, history editing, mail
> checking etc.) and a simple one only for scripting?
> I don't know if it makes a real difference though.
Something I thought about too as this would increase the size of
/rescue/sh as it's statically linked (or at least the copy of
/rescue/sh should be compiled without libedit support). It would
increase the runtime size and startup time for /bin/sh, but the text
sections should be shared and thus the overhead should be minimized
for dynamic copies of /bin/sh .
Thanks,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTin4Dpspkud2GnYLfZyo33L9uwr9u2_UMRYi_jvE>