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 ...

[Remko Lodder]

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.
>>>
>>
>> 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).
> 

getopt(3) is implemented, and it's expanded by getopt_long(3) in this 
case. The requirement is fullfilled and made more readable (in my
eyes) then before.

Not everyone agrees, too bad, the world is not perfect :-).

(I'll end discussing this with this email).

Cheers,
remko

-- 

/"\   Best regards,                      | remko at FreeBSD.org
\ /   Remko Lodder                       | remko at EFnet
  X    http://www.evilcoder.org/          |
/ \   ASCII Ribbon Campaign              | Against HTML Mail and News