Date: Thu, 5 Jun 2008 10:40:14 +0300 From: Valentin Nechayev <netch@lucky.net> To: Alexey Dokuchaev <danfe@freebsd.org> Cc: src-committers@freebsd.org, cvs-all@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: <20080605074014.GA47890@lucky.net> In-Reply-To: <20080604041815.GA84027@FreeBSD.org> References: <200805301426.m4UEQ92d025434@repoman.freebsd.org> <48405C4B.3050603@FreeBSD.org> <1212179252.1967.1.camel@localhost> <a01628140806030818te29e2fet287d59f5ceedfc9c@mail.gmail.com> <20080604041815.GA84027@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Wed, Jun 04, 2008 at 04:18:15, danfe wrote about "Re: cvs commit: src/usr.sbin": > I'd rather avoid long options in *BSD utilities. They're hard to > remember, easy to confuse, while not really gaining us anything useful > (IMHO of course). For me long options are easier to remember in many cases, because they describe the option meaning itself, not abstract mark assigned to option only due to similarity of some letter. But, of course, short options are accustomed in many cases only due to their often usage. Having long names also gives more responsibility for their correct usage, including standard names for standard roles. It concerns not only well-known cases, as "--help" or "--dry-run". For example, /bin/df has -h for 2-based human-readable print and -H for 10-based human-readable print. /bin/ls has -h for the same as /bin/df, but -H is occupied by another role. Some utilities wants -c for config file, some -C, some -d. This is good place where one well-known long name will be more suitable than asking to dig man page for each command call. The main pitfall is compatibility, as sobomax@ mentioned; one who prefers long names will use them even for old options and will have problem with porting to older releases. But this can't be fixed in other way as to ask all installed base to upgrade simultaneously. So, this shall be regulated administratively. I suppose, if an option is described in well-known standard (as Posix), we shouldn't add long-form equivalent until some real need. And, (feeding the old sleeping troll;)) the first place where long options can be really needed (but not with standard getopt* usage) is /bin/ps (to override option style). -netch-
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080605074014.GA47890>