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

[Wilko Bulte]

Quoting Steve Kargl, who wrote on Tue, Jun 03, 2008 at 09:39:55PM -0700 ..
> On Wed, Jun 04, 2008 at 04:18:15AM +0000, Alexey Dokuchaev wrote:
> > On Tue, Jun 03, 2008 at 04:18:23PM +0100, Florent Thoumie wrote:
> > > On Fri, May 30, 2008 at 9:27 PM, Coleman Kane <cokane at freebsd.org> wrote:
> > > > 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 system
> > > >> (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 system
> > > >> 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 avoided.
> > 
> > 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).
> > 
> 
> I agree.  The argument that long options are self-documenting
> in a script is rather weak.  If the command isn't obvious, then
> script writer should actually put a comment in her code.  The
> argument that -h is already taken and can't be used is also
> weak, because one can always do 'man pkg_create'.
> 
> I personally believe that commit should be backed out and core
> should establish a policy against adding long options to BSD

Gimme a break..  

-- 
Wilko Bulte				wilko at FreeBSD.org