Re: cli options

Dexter Filmore <[email protected]> Wed, 28 Jan 2004 18:07:14 +0100
Newsgroups gmane.linux.usability.annoyances
Organization SCHWA Corporation
Message-ID <[email protected]>
On Wed, 28 Jan 2004 14:08:30 +0000 (GMT)
Alex Butcher <[email protected]> wrote:

> On Wed, 28 Jan 2004, Dexter Filmore wrote:
> 
> > -O param, -Oparam, -O=param, -O='param', -option param, --option=param,
> > --option=param enable etc etc
> 
> -<single character> options are historic UNIX options provided for backward
> compatibility with existing scripts and sysadmins(!) --<option> is GNU style
> and friendlier for new users, IMHO. The others are a side-effect of the
> double-edged sword that is UNIX command line processing. There are libraries
> (e.g. <ftp://nis-ftp.lanl.gov/pub/users/jt/Software/opt>) intended to help
> developers parse command line arguments in a consistent manner, but a)
> sometimes the licenses get in the way - 'opt' is GPLv2, not LGPL, b)
> lanaguage bindings might not be available and c) sometimes the effort is of
> learning such a library is too much for a developer who (initially, at
> least) is only writing a quick hack.

Interesting, but nevertheless doesn't justifiy the situation...
Good thing developers tend to provide -O and --option today, at least on
bigger projects like (the fabulous) xine.

> 
> > even worse, all happily mixed up like in cdrecord ( -v and -eject, but
> > speed=xx and fs=xx)
> 
> At least cdrecord acknowledges it as a bug. ;-)

Good :)