Arg decoding with a template?

[Dale Strickland-Clark]

David Bolen <db3l at fitlinxx.com> wrote:

>I suppose that's a matter of taste.  Certainly in the Unix domain,
>from whence this arose, where virtually everything was traditionally
>done via the command line, all command line utilities parse their
>command lines in exactly this way, it's extremely consistent and
>trying to do other manual approaches actually makes the non-conformant
>application stand out as such.
>
>In effect, such command line parsing is a standard interface, much as
>under Windows, there's standard UI elements in its GUI.  It's also
>(unlike a GUI) designed as much for efficiency and flexibility as
>looks.
>
>You'll find that it's a flexible interface for something that has to
>deal with a textual command line.  Try designing a CLI parser that has
>optional arguments, arguments with and without values even with
>multi-character options, spacing and order insensitive, and so on, and
>you'll find yourself replicating much of the getopt behavior.
>
>Personally, since DOS/Windows command line applications never really
>formed such consistency (IMO), and at least for me I find "-" less
>glaring on the command line than "/", I find the use of a getopt
>conformant command line to be nice as well as consistency
>cross-platform.
>
>I don't know what particular user interface you are looking to serve,
>so if you're comparing this to some GUI interface to obtain
>parameters, that's not apples to apples.  But if you're working
>strictly with a command line, I wouldn't necessarily jettison getopt
>summarily.
>
>--
>-- David

I guess what I had in mind was a simple but effective equivelent that I used to use with BCPL. A
function called rdargs, which I think also became part of AmigaDOS

I've just had a quick hunt with Google and I can't find a definition for it anywhere.

I'll probably end up using getopt just because I don't have time to do a proper job right now.

--
Dale Strickland-Clark
Riverhall Systems Ltd