cvs commit: src/usr.sbin/pkg_install/add main.c pkg_add.1 src/usr.sbin/pkg_install/create main.c pkg_create.1 src/usr.sbin/pkg_install/delete main.c pkg_delete.1 src/usr.sbin/pkg_install/info main.c pkg_info.1 ...

[Brooks Davis]

On Wed, Jun 04, 2008 at 12:54:50PM -0700, Maxim Sobolev wrote:
> Remko Lodder wrote:
>>> Where do we stop?  Should we add long options to all
>>> /usr/bin utilities?  Why stop at /usr/bin, let's add
>>> long options to /usr/sbin, /bin, /sbin, /rescue, etc.

The existence of programs with long options clearly does not imply that
all programs will grow them.  If people start adding long options to
yes(1) we'll have something to discuss, but we're a long way from that
point. :)

>> That is not your call. If a maintainer wants to add all options he can 
>> consider, he is free to do so. Though others might not appreciate that as 
>> much as he does. It can be discussed ofcourse, but to a certain extend.
> 
> It's not your call either. We have style(9), which says:
> 
>      For consistency, getopt(3) should be used to parse options.  Options
>      should be sorted in the getopt(3) call and the switch statement, unless
>      parts of the switch cascade.  Elements in a switch statement that cascade
>      should have a FALLTHROUGH comment.  Numerical arguments should be checked
>      for accuracy.  Code that cannot be reached should have a NOTREACHED com-
>      ment.
> 
> There is nothing about getopt_long(3) being acceptable replacement/addition 
> to the getopt(3).

style(9) is and will remain a guideline, not a stick with which to beat
your fellow developers.  In this case there is clearly an implicit "if
your application's arguments are parsable with getopt(3)".  For an
application with long options, getopt_long(3) is obviously the right
solution.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20080604/e023472f/attachment.pgp