* GCLP (Generic Command Line Parser) 1.0.0 released @ 2012-12-14 21:17 mockturtle 2012-12-14 23:33 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 6+ messages in thread From: mockturtle @ 2012-12-14 21:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCLP (Generic Command Line Parser) 1.0.0 released 2012-12-14 21:17 GCLP (Generic Command Line Parser) 1.0.0 released mockturtle @ 2012-12-14 23:33 ` Yannick Duchêne (Hibou57) 2012-12-15 16:20 ` mockturtle 0 siblings, 1 reply; 6+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-12-14 23:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCLP (Generic Command Line Parser) 1.0.0 released 2012-12-14 23:33 ` Yannick Duchêne (Hibou57) @ 2012-12-15 16:20 ` mockturtle 2012-12-15 16:57 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 6+ messages in thread From: mockturtle @ 2012-12-15 16:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCLP (Generic Command Line Parser) 1.0.0 released 2012-12-15 16:20 ` mockturtle @ 2012-12-15 16:57 ` Yannick Duchêne (Hibou57) 2012-12-15 18:08 ` mockturtle 0 siblings, 1 reply; 6+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-12-15 16:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCLP (Generic Command Line Parser) 1.0.0 released 2012-12-15 16:57 ` Yannick Duchêne (Hibou57) @ 2012-12-15 18:08 ` mockturtle 2012-12-18 15:33 ` Brian Drummond 0 siblings, 1 reply; 6+ messages in thread From: mockturtle @ 2012-12-15 18:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCLP (Generic Command Line Parser) 1.0.0 released 2012-12-15 18:08 ` mockturtle @ 2012-12-18 15:33 ` Brian Drummond 0 siblings, 0 replies; 6+ messages in thread From: Brian Drummond @ 2012-12-18 15:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-12-18 15:33 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-12-14 21:17 GCLP (Generic Command Line Parser) 1.0.0 released mockturtle 2012-12-14 23:33 ` Yannick Duchêne (Hibou57) 2012-12-15 16:20 ` mockturtle 2012-12-15 16:57 ` Yannick Duchêne (Hibou57) 2012-12-15 18:08 ` mockturtle 2012-12-18 15:33 ` Brian Drummond
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox