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 :)