[Toybox] re using get_optflags()

[David Seikel]

On Fri, 22 Jun 2012 08:59:03 -0500 Rob Landley <rob at landley.net> wrote:

> On 06/21/2012 09:28 AM, David Seikel wrote:
> > What are the chances that get_optflags() could be made re usable by
> > toys?
> 
> Well, right now you can put a NULL as your optstring and then set
> which->options yourself and call get_optflags().
> 
> > For toys that need to make their own little scripting system for
> > example.  Currently it seems to want to use the toys global, and I'm
> > not sure if it's safe to screw with that after pulling all of my
> > toys options out of it.
> > 
> > Would it get reused like that for shell internal commands?
> 
> Already does. In toys/toysh.c function run_pipeline() look for the
> TOYFLAG_NOFORK bit.
> 
> This probably needs to be genericized somewhere in lib, but I never
> got around to it.

Yep, that's what I would like, generalize it.

> > Would be nice to just reuse all that code instead of writing
> > something similar for internal scripts and such.
> 
> Do you need something more than "a less-incomplete toysh" here? (I
> don't understand your use case...)

I'm thinking of the general case, but have a particular need for now.
At least in theory.  Really just thinking ahead and trying to
generalise stuff while I work on my design.

The "general purpose text editing library" stuff I'm working on, as
well as the "general purpose screen handling library" that goes along
with it.  You said yourself that if it's general enough, then
basic editors become configuration files.  I'm also thinking ahead and
wanting people to be able to build more advanced editors, but without
bloating out toybox.  They would be built as external scripts.

So I'm thinking that this "configuration file" might be more of a
"editor construction kit" scripting language.  At some stage we might
grow beyond simple key=value pairs for such things and need some actual
command and argument parsing.  So, I was thinking about reusing the
parsing we already have.

I'm still experimenting with my basic design, see what I can support
and still stay simple.  So far I'm surprising myself with how simple
the code is.  I had a whole list of "feature probably so complex it
should be configurable to leave it out", and finding that some where so
simple to implement that it's simpler to leave them in.

I'll investigate your suggestions, just wanted to run the basic idea
past you first before probing any further in that direction.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120623/2da58740/attachment-0004.pgp>