Bash shell support?
Rob Landley
rob at landley.net
Mon Aug 28 18:11:57 UTC 2006
On Monday 28 August 2006 7:58 am, Juergen Hennerich wrote:
> What I (also) tried to say was, that you should try to put some priority
> to also have code that could be (more or less) easily understood and
> extended. IMHO this is more important than trying to squeeze the last
> savable byte out of the code.
At this point my priority is carving out a chunk of time/energy to get a
working version I can check in. But if it's not as small as lash when it's
acting as a lash replacement (and can this actually _replace_ lash), it
doesn't go in. I'm not having _five_ shells in busybox. Not happening.
And lash is the hard one. It's the cockroach of command shells: small,
simple, obviously pathetic, and extremely well adapted to its niche...
> You have to also consider a few things (make a few design decisions)
> before you start, because they are not easy to change afterwards and
> also they might not be obvious from reading a shell manual.
Why do you think it's taken me this long? :)
> Therefore it
> would be a good idea to look into a few examples (do you know the
> advanced bash scripting guide? http://www.tldp.org/LDP/abs/html/).
That's a new one for me. (After the bash manual I have a bash FAQ queued up.)
Unfortunately, that's over 600 pages. Even double sided, that's too big to
print out and carry around with me, and I get way less read with my laptop.
(Can't read it while walking, and only half the time on the bus. The times I
can use my laptop I'm generally programming or something, not reading
documentation.)
> >> The whole language can really be brain-bending. At least if you have to
> >> read scripts from other people.
> >
> > Anybody can write code. The good ones are the ones who can _read_ code.
> >
> While this is partly true, there is also a lot of code out there, on
> which nobody should be ashamed, having troubles to read or understand it ;-)
I turned this:
http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/archival/libunarchive/decompress_bunzip2.c?rev=6751&view=markup
Into this:
http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/archival/libunarchive/decompress_bunzip2.c?rev=7664&view=markup
For fun. (Read the function BZ2_decompress() in the top version if you want
your head to explode. Yes, that's a switch statement providing essentially a
calculated goto, with case statements in the middle of loops. I had to read
and understand it all to make it stop doing that. It took a couple months.)
My limiting factors are time and energy, not code complexity...
> > I'd be willing to look at a 50k lua patch. It's at the high end of what I
> > consider a reasonable applet, but this is one I know is in real-world use
> > (even though it's a language I haven't personally picked up yet).
> >
> I've made a short test yesterday. I just added lua.c to the shell
> directory and linked busybox against liblua (statically of course). It
> adds about 87k, when compiled (lua) with generic setup and busybox is
> already linked against libmath. Obviously lua has now a few more
> features and grow a little bigger. But there are some options to omit a
> few features from lua and make it smaller.
At 50k is interesting. 87k, not as much.
> Lua is actually quite old. There is actually some threshold until you
> get it onto your radar. There are hundreds of different small scripting
> languages (or of different implementations of commonly used ones), which
> you won't notice until you start to actively search for them. Lua is
> most commonly used as embedded scripting language for applications. You
> can easily add Lua scripting to your application and if you want to have
> support for config file creation and parsing, you can either write a
> parser for yourself, which is quite some work or you can use XML or you
> can also use Lua. Which might even be more comfortable than using XML.
I don't see a major downside to having lua remain standalone, for the same
reason I don't see a major downside to having dropbear remain standalone.
BusyBox applets can be smaller by sharing code and being written with size in
mind. If it's already written with size in mind and there's not much code to
be shared...
> If I remember correctly tomsrtbt uses Lua to a) have solid scripting and
> b) to save some space, because it replaces BB applets with lua scripts,
> which is also an interesting use of Lua.
Last I checked it was using a neolithic version of busybox, but that was a
while ago...
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list