Bash shell support?
Rob Landley
rob at landley.net
Thu Aug 24 18:55:55 UTC 2006
On Thursday 24 August 2006 3:52 am, Roberto A. Foglietta wrote:
> 2006/8/23, Rob Landley <rob at landley.net>:
> > On Wednesday 23 August 2006 8:01 am, walter harms wrote:
> > > lets hear if our shell expert can implement that.
> >
> > If we have a shell expert, I look forward to hearing from them.
Personally,
> > I'm still reading up on all this stuff. (A printout of the bash man page
is
> > apparently 97 pages long.)
> >
>
> I do not know if I am an expert but since university time throught
> all 5 years of my carrer I never met a person which develop script
> shell like me. Every time I program in shell I discover something new.
I once wrote a multithreaded network server in bash. (It did the
star-topology thing to get around two systems both behind firewalls trying to
talk to each other, a bit like the VOIP supernodes causing so much
consternation these days.) I eventually _rewrote_ it in Python, but I had
the bash version working first. :)
> The last I learn is:
>
> [roberto at GEDX0327 myenta]$ hello="ciao ciao"
> [roberto at GEDX0327 myenta]$ function ciao() { echo $hello; }
> [roberto at GEDX0327 myenta]$ function miao() { local hello="ciao"; ciao; }
> [roberto at GEDX0327 myenta]$ ciao
> ciao ciao
> [roberto at GEDX0327 myenta]$ miao
> ciao
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...)
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. :)
> 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.)
Not that this is any excuse. :)
> As reference I say that this http://www.3gcam.it/ product work just
> because shell scripting which coordinates many binaries and replace
> completely log system, etc. etc.
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...
> So I am interested in developing bb-ash in order it could run bash-scripts.
Having read through maybe 25% of the ash code, I can confidently say that the
easiest way to get bash support in busybox is to start over, or at least NOT
base it on that.
> Me too are very busy: I am paid for working on three projects, I have
> a university master to finish and I would like have a life too. If
> somebody have urgency of this have to wait or to rent sombody because,
> at least, until January 2007 I would not work on it seriously.
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.
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.
But that's not _this_ week.
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list