cvs commit: src/usr.sbin/pkg_install/add main.c pkg_add.1
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 ...
sobomax at FreeBSD.org
Tue Jun 3 21:05:50 UTC 2008
Joe Marcus Clarke wrote:
> Remko Lodder wrote:
>> On Tue, June 3, 2008 5:18 pm, Florent Thoumie wrote:
>>> On Fri, May 30, 2008 at 9:27 PM, Coleman Kane <cokane at freebsd.org>
>>>> On Fri, 2008-05-30 at 12:58 -0700, Maxim Sobolev wrote:
>>>>> I am curious what is our policy on using long options in the base
>>>>> (if any)? I believe that pkg_install is the first non-contributed base
>>>>> system utility to actually widely use it. For some reason I've got
>>>>> impression that use of getopt_long is considered "the Linux/GNU way",
>>>>> this API provided for compatibility purposes and its use in base
>>>>> is discouraged. Quick grep through /use/src seemingly supports that.
>>>>> Can someone confirm/reject?
>>>> I am not sure about policy, however I do appreciate the long options
>>>> sometimes. Primarily, I think they are useful (in a self-documenting
>>>> way) for use in shell scripts. I tend to prefer the single-char options
>>>> when I am doing the administration myself.
>>> I'm not aware of such policy.
>>> I think they're useful because as far as pkg_install is concerned, we
>>> are using single-char options that are hard to match to the action
>>> it's doing. Here are a couple examples:
>>> - pkg_create -h doesn't call usage() because it's already taken.
>>> - it's easy to confuse pkg_info -o and pkg_info -O.
>>> I'll back it out if general consensus is that long options should be
>> I like the change (long opts).
> I don't see why we should abandon something that is convenient for our
> users just because Linux does it.
Apart from the BSD vs. GNU way, I think it's mistake that long
"synonyms" have been added to existing options. The reason for that is
because this is likely to promote creating superfluously incompatible
scripts/software that relies on pkg_install, as developer who develops
on say 8.0 may not be aware of the fact that in previous releases those
long options were not existing.
IMHO, long options is mostly for script writers (for whom it's harmful
in this case according to the above). It adds no convenience for a CLI
user. Except of maybe one or two options that one uses every day nobody
can really remember what world to use without looking into the man page
anyway (at which point short option wins since it's easier to type).
Maybe I am old school, but for me for example remembering `-L' in wget
it much easier than remembering `--relative'.
More information about the cvs-src