Bash shell support?

Juergen Hennerich juergen at hennerich.eu
Mon Aug 28 11:58:40 UTC 2006


Rob Landley schrieb:
> On Friday 25 August 2006 8:50 pm, Juergen Hennerich wrote:
>> Rob Landley schrieb:
[....]
>>>
>> Don't underestimate the complexity of the BASH SHell. Writing a parser, 
>> that is able to parse most of the BASH grammar is a very complex task. 
>> Especially if has to be compact, easily maintainable and extensible.
> 
> Tell me about it.
> 
> However, I'm not committing to replicating _everything_ that bash does.  Just 
> the interesting bits.  What the interesting bits are is still being figured 
> out, and will adjust after the fact based on what people complain about. :)
> 
I already guessed that.

> And you forgot "configurable".  Not just extensible but with portions able to 
> be disabled by configuration options to save space.  That pretty much has to 
> be designed in from the ground up if "maintainable" isn't to go out the 
> window.  (And the new if(ENABLE) stuff makes this a _lot_ easier than having 
> to chop up the code with #ifdefs.)
>
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.

>>> My boss (David, who is actually cool despite being my boss) keeps
>>> promising to  
>>> show me how to do call by reference in bash, which he'd need to move to 
>>> another shell.  Me, I'm up to page 9 of the bash documentation, but 
>>> resolutely working on something _else_ today (which I hope to demonstrate 
> to 
>>> co-workers tomorrow), so I should stop posting here. :)
>>>
>> You want to give a function a variable name as an argument? You can do 
>> this quite easily with eval. I have attached a few examples, how you can 
>>   do that. But you have to be very careful with eval, because eval $var 
>> executes the content of var. This works without any problems also on ash.
>> You can actually work around a lot of limitations in BASH. For example, 
>>   BASH has only one dimensional arrays and ash lacks arrays completely. 
>> But you can replace that functionality with a few eval tricks. Instead 
>> of var[x][y] you can store everything in var_x_y variables.
>> You can trick BASH to do nearly everything, that you could do with other 
>> languages (with the help of a few external tools).
> 
> I'm going to just totally ignore this for the moment, and then later get some 
> shell script fragments and expected output from people who have some trick or 
> they want to add support for. :)

This was merely to show how to do indirect referencing and how you could 
do something like putting function pointers into an array (or structure) 
and execute it in some order.

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. 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/).

> 
>>>>  if you use function in more than two level nested it easy to loose
>>>> the control about what are going on about not local variable.
>>>> Solution? Good bash programming require each function accept
>>>> parameter, check them and work just with local variable.
>>> I'd like to point out that "local" in perl is at least as brain-bending.  
> (It 
>>> essentially seems to stick a hidden "finally" clause on your current block 
>>> setting the variable back to its old value.)
>>>
>> 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'd like to collect some large test cases to test bbsh under once I get a 
>>> reasonable amount of it implemented.  Only way to find what breaks is to 
>>> break it...
>>>
>> It should be no problem to find a few more elaborate shell script
>> examples. There are even quite a few more complex scripts which are ash
>> compatible.
> 
> Going through the lash source and bash man page I'm coming up with lots and 
> lots of weird corner case tests, which I need to make a big script out of...
> 
>> Actually msh already supports a large subset of the Bourne shell. There
>> are also some patches available to implement functions. Of course the
>> noMMU people would also like to have a decent shell. There is no
>> functionality in ash that couldn't work on a noMMU system. Unfortunately 
>> it is not possible to make it work on a noMMU system without a major 
>> rewrite.
> 
> I'm using msh in a project right now, and yesterday I tracked down what seemed 
> to be a segfault in dd to actually being msh doing something weird.  (What 
> the exact weirdness is, I still need to track down and fix, but it turns out 
> not to be dd.  I think it's to do with terminal control actually.)
Thats on of the bigger trouble sources. The whole terminal system is 
somewhat inherently broken and a constant source of anger.

Of course, the biggest source of error is behind (or before if you 
prefer) the terminal. And that is not trivially to fix ;-)

> 
>> Without doubt it is a good idea to have an as small as possible as bash
>> compatible as possible shell in BB. On the other side, if there are no
>> legacy scripts to be used, wouldn't it make more sense, to use a smaller
>> ,more basic SHell and have additionally a more robust scripting language
>> also in BB. About 1 1/2 years ago, I put Lua into BB, which added about
>> 50k. There weren't even any special BB functions used, which could have 
>> saved a few extra kB. While Lua is not really one of my most favorite 
>> programming languages, it has without doubt the biggest bang for the 
>> buck (size wise).
> 
> 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.

> I first encountered lua a year or two back because it was the scripting 
> language the tomsrtbt floppy used.  And tomsrtbt is actually how I first 
> encountered busybox (years and years ago).  It seems to be coming out of 
> nowhere because it emerged from Brazil and got fairly mature with a large 
> user base before being translated into english.  (Brazil also gave us 
> Connectiva, and Marcello Tosatti the (now ex-) 2.4 maintainer, also seemingly 
> out of the blue...)
>
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.

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.

BTW. Lua (in code) is so flexible, that you can run it without big 
modifications directly on your microcontroller (without OS).

Of course if you like python, ruby or perl there is no reason to switch 
to Lua except for size constraints.

Juergen





More information about the busybox mailing list