From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,21def7b4562d91bf
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,CP1252
Received: by 10.224.218.2 with SMTP id ho2mr4953980qab.8.1355594885766;
        Sat, 15 Dec 2012 10:08:05 -0800 (PST)
Received: by 10.49.71.169 with SMTP id w9mr1713997qeu.7.1355594885750; Sat, 15
 Dec 2012 10:08:05 -0800 (PST)
Path: 
 k2ni7qap.0!nntp.google.com!fc2no939238qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sat, 15 Dec 2012 10:08:05 -0800 (PST)
In-Reply-To: <op.wpdaph0qule2fv@cardamome>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=93.37.82.182;
 posting-account=9fwclgkAAAD6oQ5usUYhee1l39geVY99
NNTP-Posting-Host: 93.37.82.182
References: <0160c8ce-1e7c-4e2c-9641-c76502adadd9@googlegroups.com>
 <op.wpbyefvfule2fv@cardamome>
 <9e1a279f-5dc0-47a8-8196-05de1f95e9da@googlegroups.com>
 <op.wpdaph0qule2fv@cardamome>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <142eeaa9-839c-412e-8eec-c7aff4ef8b8b@googlegroups.com>
Subject: Re: GCLP (Generic Command Line Parser) 1.0.0 released
From: mockturtle <framefritti@gmail.com>
Injection-Date: Sat, 15 Dec 2012 18:08:05 +0000
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: 2012-12-15T10:08:05-08:00
List-Id: <comp.lang.ada>

On Saturday, December 15, 2012 5:57:07 PM UTC+1, Hibou57 (Yannick Duch=EAne=
) wrote:
> Le Sat, 15 Dec 2012 17:20:19 +0100, mockturtle <framefritti@gmail.com> a =
=20
>=20
> =E9crit:
>=20
> > I agree that this differentiates itself from the usual syntax.  I choos=
e =20
>=20
> > this approach (and wrote this package) once that I needed to write a =
=20
>=20
> > program with a fairly complex syntax and with many possible variations.
>=20
>=20
>=20
> If the command line become too complex, that may suggest the command is =
=20
>=20
> not well suited for the matter. May be a configuration file or project =
=20
>=20
> file, using XML, could be an option. Compare this to some program in some=
 =20
>=20
> wrong language, becoming unmaintainable, suggesting to use another one.
>=20

Yes, I understand, but between a simple command like

      cp src dst

and a command that makes it convenient to give parameters via a configurati=
on file (maybe in XML format), there is a gray area where a positional synt=
ax is too complex (was the port number the first parameter?  or the third?)=
, but the complexity of a configuration file is not justified (maybe also b=
ecause you use the command only once). In that gray area a syntax like this=
, in my opinion, becomes convenient. =20

I like this syntax also because it makes calls in  shell scripts a bit more=
 readable. As a quasi-real life example, recently we wrote a program that t=
akes a directory full of images, process them and write the result in anoth=
er directory.  A (more or less) realistic call for this program could be

  process  input-dir=3D/foo/bar zoom=3D9 area=3D128x128 output-dir=3D/bar/f=
oo

this is a bit more readable (inside a script) than

  process  /foo/bar /bar/foo 9 128x128=20

Of course, if you prefer more standard names like "--input-dir", you can us=
e them.

>=20
>=20
> The command line is not the place for a complex syntax (except if it's an=
 =20
>=20
> interactive shell, and still with quickly reached limits=85).
>=20
>=20

The example above shows what I mean with "complex syntax" (maybe it is not =
a perfect choice of words): a command that requires a fair number of parame=
ters (say, more than 3-4), some of which can be optional.  If the syntax wa=
s such that you need to express, say, conditionals or complex dependencies =
between parameters (the command line syntax of VLC comes to my mind :-/), t=
hen I agree that a structured configuration file is way better (but not in =
XML, please! :-) I hate to parse XML... :-) [even with specialized librarie=
s].

>=20
>=20
>=20
> --=20
>=20
> =93Syntactic sugar causes cancer of the semi-colons.=94 [1]
>=20
> =93Structured Programming supports the law of the excluded muddle.=94 [1]
>=20
> [1]: Epigrams on Programming =97 Alan J. =97 P. Yale University