Re: bug in sh, probably, with test case

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sat, Dec 22, 2012 at 05:37:27PM +0100, Julio Merino wrote:
> On Sat, Dec 22, 2012 at 4:55 AM, Thor Lancelot Simon 
> <tls%panix.com@localhost> wrote:
> >
> > At least as it seems to be in the version of Debian I use, it lacks many
> > useful features for interactive use, like history and editing.  If it
> > started its life as our shell, I cannot see why those features would
> > have been taken out.
> 
> IIRC, the whole point of dash was to have a small, standards-compliant
> and fast shell interpreter for the execution of scripts. Interactive
> use is explicitly not a goal, and therefore explains why the features
> were yanked.

Not really.  For that explanation to be valid, I'd have to believe that
removing those features actually made the Debian shell significantly
smaller or faster than ours.

It looks to me like it's a little smaller -- 30%, but the absolute
executable sizes are small (100K vs 130K) -- but it depends on glibc,
which is about 300K (30%) larger than our libc + libedit + libtermcap
together.  So the total code size to be able to have this thing on
your system is (admittedly, considered in isolation) larger than to
have what they started with.

A better test might be to statically link each of them.  I'd like to
see the results of that but I'm not in a hurry to figure out how to
statically link dash myself.

Now, "faster" for a shell is hard to test, though I note that we usually
do quite well in most tests.  But I don't see how ripping out libedit
support and the other interactive features  would actually make any
difference there.

From my point of view, we have a small, fast shell that's also good for
interactive use.  They turned it into a small, fast shell that's really
awful for interactive use.  I can't see why that's a good outcome.

Thor