David Bolen <db3l@[...].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 BCP
L. 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 no
w.

--
Dale Strickland-Clark
Riverhall Systems Ltd
-- 
http://mail.python.org/mailman/listinfo/python-list