Bill Sommerfeld <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-07-14 at 20:40, John Martinez wrote:
> > Am I the only one that doesn't like the --something-or-other options
> > of GNU related software? Please don't do this to Solaris!
>
> A couple years ago we had a very long, very painful discussion about
> this topic under the name of "CLIP".
>
> Opinions on both side of this issue tend to run very strong, and I
> really don't want to relive the experience.
>
> Given that there is a substantial body of code out there using various
> getopt_long() variants, we felt that we had to provide it in core
> solaris, but the (rougher than usual) consensus we came to was that, in
> code we "owned":
>
> 0) as the GNU getopt_long() violates POSIX expectations for argument
> parsing in some fine point which escapes me at the moment, we also
> supply a getopt_clip() which doesn't.
A big problem with GNU getopt_long() is that it reorders the argument vector.
> 1) all long-options must have a short-option equivalent.
This is not possible.
Note that star curently has 167 options.
> 2) utilities should only be written (enhanced) to the long options part
> of the CLIP specification in "logical groups". (i.e., a group of
> related utilities should be consistent in their use or non-use of long
> options).
This is true for all "schily" commands but nit true for GNU commands in
general.
> 3) there is no compelling reason to inflict long options on the vast
> majority of code in the ON consolidation; the initial reaction to anyone
> seeking to do this should approximate "can't you find something better
> to do?"
A big problem with introducong long option equivalents to short options
is that people would use them and this way lean a habbit that is not
compatible with POSIX.
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
opensolaris-discuss@opensolaris.org
