[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] Re: getopt() as gtroff macro ?
From: |
Keith Marshall |
Subject: |
Re: [Groff] Re: getopt() as gtroff macro ? |
Date: |
Fri, 24 Sep 2004 03:34:14 +0100 |
On Thursday 23 September 2004 12:20 pm, Werner LEMBERG wrote:
> > >> I think this is important and, while I admire what Keith has
> > >> done, I wonder if there's any way to get a getopt built into
> > >> gtroff?
> > >
> > > Nice idea. What exactly do you have in mind? Can you make syntax
> > > suggestions?
> >
> > I agree, this would be a nice feature to have. Perhaps something
> > along the lines of the shell's built-in 'getopts' command?
> >
> > The main problem I foresee is, how do you implement the call backs
> > needed, to allow getopt's caller to handle the optional arguments as
> > they are parsed? This could end up being no simpler than the
> > technique I suggested earlier, but it would be great if we can
> > identify a viable solution.
>
> What about the following (inspired by Python's getopt module):
>
> .getopt <prefix> <options> <long options>
>
> Example:
>
> .de foo
> . getopt "foox" "ac:" "--all --check="
> . ...
> ..
Would the .getopt request not need to also include the arguments of the
invoking macro? Thus, this example would become:
.de foo
. getopt "foox" "ac:" "--all --check=" \\$@
. ...
..
> The .getopt command would call the functions `<prefix>-<option>', passing
> the corresponding values as arguments. `<prefix>-?' (with <option> as
> the argument) is called if <option> is invalid. Finally, all
> non-option arguments are passed to a macro called `<prefix>'.
>
> Calling the above function like this
>
> .foo -a -c bar --all --check=urgh --xxx arg1 arg2
>
> would consequently call the functions
>
> .foox-a
> .foox-c bar
> .foox--all
> .foox--check urgh
> .foox-? --xxx
> .foox arg1 arg2
So, basically the user's macro implementation would become very similar to my
original suggestion, simply offloading the option parsing loop within my
.pdfhref-L macro to the .getopt request, but retaining everything else much
the same, perhaps with some changes in the naming convention for the option
handler macros being required to fit the .getopt paradigm.
This is not to say that a .getopt request is unnecessary -- indeed, it would
offer significant advantages, amongst which:
- the user is relieved of the onus for providing the parsing loop, with
its associated need for shifting the arguments, (and the requirement for
maintaining an 'argc' register, to control the shifting process).
- the set of options considered 'valid' is more clearly, and rigidly,
defined.
- a mistyped option can be trapped, and diagnosed, rather than simply
accepting it as the first non-option argument; this is a major weakness
in the sample implementation I provided -- not impossible to achieve
without a .getopt request, by using the .substring request instead, to
check for '-' at char 0 of \\$1, but it would make the option parsing
loop rather more complex.
> It probably makes sense to provide a .gnu-getopt request also to
> reorder the arguments.
I'm not sure I understand the need for this, unless you mean to support
intermixing of option and regular arguments, in any order -- but could a
simple .getopt request not provide this capability in any case? Perhaps a
register, say \n[getopt-strict], could be used to select between strict and
flexible ordering, if a need for this is perceived.
Best regards,
Keith.
[Groff] Re: getopt() as gtroff macro ?, Steve Izma, 2004/09/23
Re: [Groff] Re: getopt() as gtroff macro ?, Keith MARSHALL, 2004/09/24
Re: [Groff] Re: getopt() as gtroff macro ?, Keith MARSHALL, 2004/09/24