On Wed, Jul 18, 2012 at 3:37 PM, David Korn <d...@research.att.com> wrote:
> cc: ast-developers@research.att.com
> Subject: Re: Re: AST busybox ... / was: Re: [ast-developers] Patch for
> seamless grep.c integration into libcmd
>> Well... I have plans for that... but I need to probe carefully whether
>> you and Glenn like the idea (which is basically to use DocBook/XML as
>> "master source" for all manpage/getopts stuff and build the
>> _ast_getopts strings at build time... with options for full coverage
>> (the default), reduced builtin documentation or only the minimal set
>> for short and long options (the advantage would be that DocBook/XML is
>> an industry standard which would _VASTLY_ simplify many things...
>> including promo material generation and the translation of the
>> manpages (there have been significant complains from the
>> Sun^H^H^HOracle documentation folks because they were not able to
>> handle the situation (e.g. "alien" tools, non-standard procedures and
>> no clue how to handle that even after many explanations) ... instead
>> they dumped the output of somebuiltin --html and translated that and
>> leaving the other options etc. untranslated))).
>
> If the translation is reversable it is a good idea. I should be
> able to edit the getopts string, and then have DocBook/XML updated
> as well as update DocBook/XML and have getopts strings updated.
Erm... the DocBook/XML----> _ast_getopts string translation is lossy
because DocBook can contain much more information (for beginners:
DocBook/XML is not like (X)HTML and describes the layout (e.g. which
fonts or color is being used or whether something should be bold,
italic or not) ... instead DocBook "tags" the information on a
per-purpose information.
For example a fragment for a AST mkdir(1) man page would look like
this (<para> means "paragraph"):
-- snip --
<variablelist>
<varlistentry>
<term><option>-m</option></term>
<term><option>--mode</option>=<replaceable>mode</replaceable></term>
<listitem>
<para>Set the mode of created directories to mode. mode is
symbolic or octal mode as in <citerefentry>
<refentrytitle>chmod</refentrytitle>
<manvolnum>1</manvolnum>
</citerefentry>. Relative modes assume an initial mode of
<literal>a=rwx</literal>.
</para>
</listitem>
</varlistentry>
<!-- Add more varlistentrys with the same structure -->
</variablelist>
-- snip --
So the conversion _ast_optget would be more or less a one-time event
and then we would use a simple utility which fetches the DocBook/XML
input to generate the _ast_getopts string.
The hard part is that I previously crafted such utilities using ksh93
(to make use of .sh.match and other pattern matching facilities). But
this won't work because we want to build ksh93 itself. The other
(XML-traditional) option is to use "xsltproc" ... but that is not an
option because it depends on libxml2 which drags-in quazillion of
other shared libraries as dependicies (like Windows dependicy hell^2)
...
... which leaves me stuck with implemeting a tool myself... by hand
... in ANSI C (not hard... just work...). The only "happyness" I can
see that I can (hopefully) use libast (basically I need a XML tag
tokeniser like
http://svn.nrubsig.org/svn/people/gisburn/scripts/xmlfragmentparse.sh
written in C... the remainder is just the funny
"hack-the-logic-until-it-works"-game) ...
... but before I do that I need feedback from David&&Glenn whether
they like the idea (e.g. for ksh93 it means the getopts strings in
src/cmd/ksh93/data/builtins.c will be converted into DocBook/XML and
stored in this format in the source (e.g. the DocBook/XML manpages
would be the master file) ... and during built time we build a C file
with _ast_getopts strings)
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
