Rich Teer <[EMAIL PROTECTED]> wrote:
> > This is really strange, so you like the hard to memorize options from cdrw?
>
> The only cdrw options I've used are -i, -M, and -C (and -i is by far the
> most often one I use).
They are hard to memorize even if there are only a few of them.
-C is not needed because if you have a reasonable implementation, this always
checks the real size of the medium.
> > Well, it does not support many of them.... tell me how you would design a
> > program that supports nearly 100 options without using long options.
> > Tell me how you would design a program like star that supports more than
> > 170
> > options?
>
> I would rethink the design such that so many options weren't required. :-)
I of course offer a well reconsidered CLI concept that is compliant with POSIX.
The options are needed of course. You need them to support the features cdrecord
offers to you.
Note that I am not adding silly options with limited use into my programs
but try to plan options with a more general usage in advance.
Let me make an example with GNU tar. GNU tar recently added a lot of not
well planned new options. You cannot do much with them but the number of
options did increase noticably.
Star on the other side added "libfind" and as a result, you now may now use
well known find(1) expressions with a lot more "generic option power" than the
specialized and badly planned new options in GNU tar.
> Seriously though, if long option are unavoidable, fine, but I would at least
> stick to the POSIX guidelines* for doing so, modulo using -- to introduce a
> long option. In otherwords, I'd use "--longoption" rather than "-longoption".
> The latter could be confused with grouped arguments (i.e., the grouping of
> -l -o -n and -g).
I am using long options since 1982.
If UNIX did have a library routine to parse long options at that time,
many "historical UNIX tools" would now use easy to memorize long options
instead of hard to memorize short options.
In case you did not notice, my programs are designed with a CLI that is a
careful extension to the classical UNIX phiolosophy CLI.
And finally answering your paragraph from above: my command line parser
is POSIX compliant an allows to use all CLI methods for all POSIX rules.
My command line parser does not have the bugs and oddities you may know
from GNU getopt_long() in case you did carefully analyze strange application
behavior with odd but legal variants of the CLI.
As a final note: star is e.g. providing a 100% SUSv2 "tar" CLI. Star carefully
adds it's enhanced CLI on top of the SUSv2 CLI for "tar" while regarding
latest POSIX rules. GNU tar is unfortunately not implementing a 100% correct
SUSv2 "tar" CLI and many complaints I see against star are caused by the fact
that people are customized to the non-SUSv2 GNU tar CLI.
> * See the "Utility Syntax Guidelines" in Chapter 12 of the XBD section
> of the SUSv3.
see my explanations from above: I am following these rules and you should
know that there is a consensus in the POSIX standards mailing list that
POSIX.1-2001 does not forbid long options in case that they are not
implemented in a way that contradicts the utility guidelines.
My getargs()/getallargs()/getfiles() implementation is a powerful option parser
that follows the rules...and it is used in all my software since 1982.
I am sure that once you try to understand the general rules I use for
extending the POSIX CLI utility guidelines, you will like my programs
and prefer them before others. Many people who did go this way do already.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
[email protected]
