More bbsh design notes.

[Rob Landley]

On Thursday 14 September 2006 9:57 pm, Rich Felker wrote:
> On Thu, Sep 14, 2006 at 04:38:34PM -0400, Rob Landley wrote:
> > Also note that there are two types of shell variables; local and 
environment.   
> > And yes, unset needs to know about both kinds...
> 
> One comment about this: it might make more sense to implement them as
> the same thing and just keep a flag for each indicating whether it's
> exported. If you use setenv/putenv/unsetenv it's very difficult to
> avoid leaking memory (and implementation-dependent; afaik glibc always
> leaks memory here in the name of being "safe").

I can test that last parenthetical with a loop pretty easily. :)

> On the other hand, 
> just keeping all variables in your own structure and setting up the
> environment at exec-time is easy.

Might be a good idea, and it's an easy way to reuse code, but the downside is 
that I want to have a config option for the local variables, and this way the 
local variable infrastructure becomes required if you want to have _any_ 
environment variables.

Remember, I'm trying to get the code to config down as small as lash with 
lash's functionality.  And lash doesn't have local variables...

> BTW there may be additional issues I'm not thinking of that come up
> when you want to support no-MMU systems..?

I'm trying to take those into account.  That's part of the reason it's such 
slow going.  (The version in the tree has an allocation for each argument, 
although these are small allocations and not long-lasting.  It's a 
trade-off...)

> > > Wants a table for these builtins and chdir et al.
> > 
> > I mentioned that, yes.  It's possible that the if/else staircase would be 
> > smaller, but the table would be more maintainable, and I haven't decided 
yet.  
> > I'm still writing it.
> 
> The single string approach with embedded nulls, then a switch
> statement based on the number of nulls that were counted, can give
> very small code (jumptable is small since the cases are all
> consecutive).

Bit of a pain to declare and maintain, though.

> > It's not to the point where multiple people can really work on it yet.
> >  I've
>
> I agree, just throwing in some ideas that might or might not be
> useful.

Oh I appreciate the feedback, it's just a bit frustrating how slow the 
progress is.  (Lotsa work, this...)

Rob
-- 
Never bet against the cheap plastic solution.