Date: Wed, 4 Jun 2008 15:22:27 -0500 From: Brooks Davis <brooks@FreeBSD.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: Alexey Dokuchaev <danfe@FreeBSD.org>, src-committers@FreeBSD.org, Florent Thoumie <flz@FreeBSD.org>, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Steve Kargl <sgk@troutmask.apl.washington.edu>, Wilko Bulte <wb@freebie.xs4all.nl>, Remko Lodder <remko@FreeBSD.org>, Coleman Kane <cokane@FreeBSD.org> Subject: Re: 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 ... Message-ID: <20080604202227.GA79834@lor.one-eyed-alien.net> In-Reply-To: <4846F30A.5070204@FreeBSD.org> References: <1212179252.1967.1.camel@localhost> <a01628140806030818te29e2fet287d59f5ceedfc9c@mail.gmail.com> <20080604041815.GA84027@FreeBSD.org> <20080604043955.GA38627@troutmask.apl.washington.edu> <20080604063631.GA28351@freebie.xs4all.nl> <20080604150013.GA44358@troutmask.apl.washington.edu> <20080604191339.GA31570@freebie.xs4all.nl> <20080604192955.GA46284@troutmask.apl.washington.edu> <4846EF10.1020803@FreeBSD.org> <4846F30A.5070204@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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= =20 >> consider, he is free to do so. Though others might not appreciate that a= s=20 >> much as he does. It can be discussed ofcourse, but to a certain extend. >=20 > It's not your call either. We have style(9), which says: >=20 > For consistency, getopt(3) should be used to parse options. Options > should be sorted in the getopt(3) call and the switch statement, unl= ess > parts of the switch cascade. Elements in a switch statement that ca= scade > should have a FALLTHROUGH comment. Numerical arguments should be ch= ecked > for accuracy. Code that cannot be reached should have a NOTREACHED = com- > ment. >=20 > There is nothing about getopt_long(3) being acceptable replacement/additi= on=20 > 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 --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIRvmDXY6L6fI4GtQRAgeUAJsFBF/2aAo5sZeO9jZiNmanD2zWMQCeKItQ sbkAVOqixIQX7eNfdfVV9Bc= =Krfc -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080604202227.GA79834>