Bash shell support?

Juergen Hennerich juergen at hennerich.eu
Sat Aug 26 00:50:15 UTC 2006


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.

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

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

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

> I should definitely have the first drop of bbsh in before 2007.  I was working 
> on it last night.
> 
> Ideally I want my first drop to replace _lash_, since that's the real blocker 
> that prevents any of the other shells from being a good base.  None of them 
> can config down as small as lash.  (Because it's _hard_.)
> 
> Then replace msh (yes, this means being a good citizen on nommu) and hush.  
> Then skip ash and go straight for bash, based off of the bash man page.
>

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.

> Speaking of which, on page 7 of the bash man page under the [[ expression ]] 
> bit, does anybody know what "The return value is 0 if the string matches or 
> does not match the pattern, respectively, and 1 otherwise." actually _MEANS_?  
> I'm guessing they meant was "the return value is 0 if the string matches the 
> pattern, and 1 if it does not match the pattern."  That's how I plan to code 
> it, anyway.
>

Obviously this sentence doesn't make any sense. Every other behavior, 
different from True => 0 and False => !0 is wrong.

> But that's not _this_ week.
> 

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

Juergen

> Rob


-------------- next part --------------
A non-text attachment was scrubbed...
Name: indirect_reference_example.sh
Type: application/x-shellscript
Size: 2456 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20060826/8c5464f7/attachment.bin 


More information about the busybox mailing list