Bash shell support?

Rob Landley rob at landley.net
Sat Aug 26 19:33:01 UTC 2006


On Friday 25 August 2006 8:50 pm, Juergen Hennerich wrote:
> Rob Landley schrieb:
> 
> > 
> > Bash maintains nested internal variable lists, which get inherited by 
> > functions you call.  (You'll notice that lash has "export" but no set: the 
> > actual OS level environment variables are different from the ones you 
haven't 
> > exported yet...)  And yes, I'll have to implement this, but it will have a 
> > config option.  (Along with terminal control, pipes/redirect, source/here 
> > documents, job control, flow control statements...  And the local 
environment 
> > variables option needs a _sub_ option for synthetic variables like $RANDOM 
or 
> > $PPID...)
> > 
> > Which is why I need a grouping option that lets hidden options have a 
value 
> > other than "no".  (Sigh: everything depends on everything else...)
> > 
> 
> 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. :)

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

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

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

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

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

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list