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

[Valentin Nechayev]

 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-