Re: cli options

On Wed, 28 Jan 2004, Dexter Filmore wrote:

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

No, but it helps explain why things are the wayy they are. If you want
consistent command line options, you're more likely to find them in OSs that
have been developer "all under one roof" - e.g. BSD or Solaris. I don't
think it would possible to achieve the same, with Linux, from where it is
now without a single distro vendor putting a lot of tedious work (which
needs to be paid for, somehow), forking packages that won't accept their
changes, and accepting they'll be incompatible in numerous ways with "every
other Linux".

I can't see it happening.

Best Regards,
Alex.
-- 
Alex Butcher      Brainbench MVP for Internet Security: www.brainbench.com
Bristol, UK                      Need reliable and secure network systems?
PGP/GnuPG ID:0x271fd950                         <http://www.assursys.com/>