I can't commit right now because all of the implications are not clear
it feels like a longer term issue requiring more thought
rather than lets start coding next week
an intriguing thought from these posts though is preprocessing the option string
into another string for faster option parsing -- this could maybe
replace the option parse caching in optget() -- the issue not attacked
by the current cache is --long-options
On Wed, 1 Aug 2012 09:38:02 -0400 David Korn wrote:
> > Well... first I need to know whether you like the general idea. Please
> > choose... :-)
> >
> > [ ] like the idea
> > [ ] don't like the idea
> > [ ] need more time to think
> > [ ] no idea
> > [ ] more coffee
> > [ ] Elvis Presley is alive <giggle> on mars !!
> > [x] option of choice not listed
> >
> >
> I don't think that it is doable. Going from optget() format to
> docbook will work, but not the other way.
> For example, for stty, the list of options are not in the
> optget ussage string. The optget usage string generates these
> from a table that is used by a function that is given to optget().
> Here is what the table looks like. The last field is used by
> optget and appears in the documentation. The rest is used
> by the code that implements stty.
> static const Tty_t Ttable[] =
> {
> { "ispeed", NUM, C_SPEED,0, CBAUD, 0, C("\an\a is the input baud
> rate") },
> { "ospeed", NUM, C_SPEED,0, CBAUD, 0, C("\an\a is the output baud
> rate") },
> ....
> }
> David Korn
> d...@research.att.com
> _______________________________________________
> ast-developers mailing list
> ast-developers@research.att.com
> https://mailman.research.att.com/mailman/listinfo/ast-developers
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
