GCLP (Generic Command Line Parser) 1.0.0 released

GCLP (Generic Command Line Parser) 1.0.0 released

[mockturtle]

Dear.all,
this is small thing, but maybe someone could find this useful.

I just released on Launchpad (https://launchpad.net/gclp/1.0/1.0.0) the very first release of GCLP (Generic Command Line Parser).

I almost can hear you: "Not yet another command line parser!" :-)  Yes,  I know that there are few command line parsing libraries, but I was not able to find one that I liked, so... I scratched my own itch.

A peculiarity of GCLP, that I find very convenient for commands with many parameters, is that the parameters are nominal and not positional.  For example,

   fictional.exe input=foo.txt output=bar.xml

Riccardo

Re: GCLP (Generic Command Line Parser) 1.0.0 released

[Yannick Duchêne (Hibou57)]

Le Fri, 14 Dec 2012 22:17:17 +0100, mockturtle <framefritti@gmail.com> a  
écrit:
>    fictional.exe input=foo.txt output=bar.xml
If that's a real life example, then it does not follow the standard on  
Windows platform (as that's an *.exe), which is to use a slash prefix for  
parameters.

One nice feature of a command line parser I believe, is to allow to be  
close to the platform standard. There's already too much inconsistencies  
with too many applications not following any common standard. In return,  
this make the command line interaction more intuitive and straight away.

That's just a personal opinion.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: GCLP (Generic Command Line Parser) 1.0.0 released

[mockturtle]

On Saturday, December 15, 2012 12:33:41 AM UTC+1, Hibou57 (Yannick Duchêne) wrote:
> Le Fri, 14 Dec 2012 22:17:17 +0100, mockturtle <framefritti@gmail.com> a  
> 
> écrit:
> 
> >    fictional.exe input=foo.txt output=bar.xml
> 
> If that's a real life example, 

No, it is not a real life example.  I just added .exe to emphasize that "fictional" was a command.

> then it does not follow the standard on  
> 
> Windows platform (as that's an *.exe), which is to use a slash prefix for  
> 
> parameters.

Do you mean something like 

           fictional.exe /input=foo.txt /output=bar.xml

Well, you could do this as well, by setting the parameter names to "/input" and "/output".  By the way, the real "translation" of this under Linux would be

           fictional.exe --input=foo.txt --output=bar.xml

and you can do this as well, by using "--input" and "--output" as parameter names.

> 
> 
> 
> One nice feature of a command line parser I believe, is to allow to be  
> 
> close to the platform standard. There's already too much inconsistencies  
> 
> with too many applications not following any common standard. In return,  
> 
> this make the command line interaction more intuitive and straight away.

I agree that this differentiates itself from the usual syntax.  I choose this approach (and wrote this package) once that I needed to write a program with a fairly complex syntax and with many possible variations.  So, I decided for this approach that, you could say, have no (positional) parameters, but only options.  In this case, the "--", "-" or "/" necessary to mark an option became redundant.   Nothing prevents you to put that back in the option name, if you desire.

> 
> 
> 
> That's just a personal opinion.
> 
> 

Thank you for your interest.

Riccardo

> 
> 
> 
> -- 
> 
> “Syntactic sugar causes cancer of the semi-colons.” [1]
> 
> “Structured Programming supports the law of the excluded muddle.” [1]
> 
> [1]: Epigrams on Programming — Alan J. — P. Yale University

Re: GCLP (Generic Command Line Parser) 1.0.0 released

[Yannick Duchêne (Hibou57)]

Le Sat, 15 Dec 2012 17:20:19 +0100, mockturtle <framefritti@gmail.com> a  
écrit:
> I agree that this differentiates itself from the usual syntax.  I choose  
> this approach (and wrote this package) once that I needed to write a  
> program with a fairly complex syntax and with many possible variations.

If the command line become too complex, that may suggest the command is  
not well suited for the matter. May be a configuration file or project  
file, using XML, could be an option. Compare this to some program in some  
wrong language, becoming unmaintainable, suggesting to use another one.

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


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: GCLP (Generic Command Line Parser) 1.0.0 released

[mockturtle]

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

Yes, I understand, but between a simple command like

      cp src dst

and a command that makes it convenient to give parameters via a configuration file (maybe in XML format), there is a gray area where a positional syntax 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 because you use the command only once). In that gray area a syntax like this, in my opinion, becomes convenient.  

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 takes a directory full of images, process them and write the result in another directory.  A (more or less) realistic call for this program could be

  process  input-dir=/foo/bar zoom=9 area=128x128 output-dir=/bar/foo

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

  process  /foo/bar /bar/foo 9 128x128 

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

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

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 parameters (say, more than 3-4), some of which can be optional.  If the syntax was such that you need to express, say, conditionals or complex dependencies between parameters (the command line syntax of VLC comes to my mind :-/), then I agree that a structured configuration file is way better (but not in XML, please! :-) I hate to parse XML... :-) [even with specialized libraries].

> 
> 
> 
> -- 
> 
> “Syntactic sugar causes cancer of the semi-colons.” [1]
> 
> “Structured Programming supports the law of the excluded muddle.” [1]
> 
> [1]: Epigrams on Programming — Alan J. — P. Yale University

Re: GCLP (Generic Command Line Parser) 1.0.0 released

[Brian Drummond]

On Sat, 15 Dec 2012 10:08:05 -0800, mockturtle wrote:

> On Saturday, December 15, 2012 5:57:07 PM UTC+1, Hibou57 (Yannick
> Duchêne) wrote:

>> If the command line become too complex, that may suggest the command is
>> 
>> not well suited for the matter. May be a configuration file or project
>> 
>> file, using XML, could be an option. 

> Yes, I understand, but between a simple command like
> 
>       cp src dst
> 
> and a command that makes it convenient to give parameters via a
> configuration file (maybe in XML format), there is a gray area where a
> positional syntax 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 because you use the command only once). 

Perhaps you can combine the two modes : the GCLP could read a complex 
command line, or some/all of the options - in the exact same syntax - 
from file. It would make refactoring complex command lines effortless...

- Brian