lua [ was: Bash shell support? ]

Bernhard Fischer rep.nop at aon.at
Mon Aug 28 20:01:13 UTC 2006


On Mon, Aug 28, 2006 at 03:31:47PM -0400, Rob Landley wrote:
>On Monday 28 August 2006 6:28 am, Bernhard Fischer wrote:
>> Why on earth do we want any scripting _in_ busybox?
>
>You mean like lash, msh, hush, ash, and bbsh?

Nah.. If you start with those, then one would have to add sed, awk,
ed,.. too, with may be strictly correct but not strictly a
scripting-language. They are implementing established tools, at least.
>
>> AFAIR, we don't want (resp. didn't want until recently) these in busybox
>> -) filesystem utilities (bad example as there currently is a big bloated
>>    batch in there -- e2fsprogs -- that noone cares to shrink nor really
>>    maintain)
>
>Actually I'm about 1/2 way through a from-scratch mke2fs rewrite.  

Don't get me wrong, but that one is utterly and completely offtopic at
any rate. There are much more worthwile things to cleanup that are
generally useful, except filesystem maintenance stuff.

I'd have turned e2fsprogs off in about all *config targets for a loong
time, if it was up to me. Same for the partitioning stuff. These make up
for a nice "Extra tools" config submenu that is off by default and
states that it is mostly bloat and seldom used anyway -- just add a
full-blown sfdisk or xyz_fsprogs if you really think you need to
support/provide it.

[snip i-have-to-meet-deadlines-too]
>> -) compilers (i'd immediately put in tcc, because it is relatively small
>>    -- <100k -- and relatively useful, as in somewhat useable C89 support)
>
>I'd like BusyBox to build with tcc.  (I subscribed to the tcc mailing list but 
>have yet to get a message on it.)  If I had more time I'd try to get that to 
>be a better gcc replacement (for starters, building the kernel...)

build with != incooperate with. My cp of tcc is <100k and compiles most
of busybox (modulo sed and other ...stuff).
>
>Seems a bit stalled now that Fabrice has his hands full with qemu...

Unfortunate but true. Could need a different upstream, as it stands ;-)
>
>> One project that may be of real use is to export a zlib compatible
>> interface, as mentioned before, but i didn't yet see any proposal for
>> this one.
>
>If someone would like to do this, I'm all for it.  (It's probably best if 
>libbb.so did this.  When I cycle back around to working on scripts/individual 
>again, I need to not just fix the rest of the apps to build right but add 
>libbb.so support.)

Trivial since all the major bits are already in place :)
>
>Oh, a recent discussion on linux-kernel suggested that the "build at once" 
>mode should be a separate target (which seems obvious in retrospect), and I 
>think possibly libbb.so should also be a separate target.

No idea what that could be, TBH. Sounds like it's just fixups for
non-GNU-complete drop-in libc's, ultimatively. Dunno, though.
>
>Possibly we should have a number of targets:
>
>busybox (default)
>busybox-static
>busybox-shared (with libbb.so automatically built).
>
>Maybe these are .dummy targets, or maybe actual executable names.

Well, that's what 'make *config' is for, isn't it? ;)

Given the current brokenness of lxdialog, i'm all in favour of adhering
to the caveats of the kernel's fork of dialog an plain not using it.

>From what i've seen, it is a pain to beat into collaboration and
furthermore clearly states that it is expected to be. YMMV, resp.
clearly does..
>
>I'm holding off on poking at the build system until Denis finishes up his port 
>of the current linux-kernel/klibc stuff to BusyBox.
>
>Rob



More information about the busybox mailing list