Commandline Option Parsing
Markus Raab
I would need a small and specialiced Library for commandline option parsing.
It must be BSD licenced (not GPL/LGPL). It should be header-file only
and/or very small to be full included in the project.
It should not handle Environment, Configuration files or similar, please
option parsing only. (So Boost::Program_options sounds like overkill for
me)
But it should also handle long options well.
Up to now I mainly used getopt_pp, but I can't use it because of the licence
(its a BSD licenced project). The streaming API is really easy. Another
approach would be to write the options in another language or an embedded
language realized with Meta-Programming (like boost::spirit) which yields a
code which is suitable to parse specific options for an application only.
Is there a project doing that?
best regards
Markus
--
http://www.markus-raab.org | Unendliches verdankt die Welt den Mï¿œttern.
-o) | -- Johann Peter Uz
Kernel 2.6.24-1-a /\ |
on a x86_64 _\_v |
Öö Tiib
> I would need a small and specialiced Library for commandline option parsing.
> It must be BSD licenced (not GPL/LGPL). It should be header-file only
> and/or very small to be full included in the project.
>
> It should not handle Environment, Configuration files or similar, please
> option parsing only. (So Boost::Program_options sounds like overkill for
> me)
>
> But it should also handle long options well.
>
> Up to now I mainly used getopt_pp, but I can't use it because of the licence
> (its a BSD licenced project). The streaming API is really easy. Another
> approach would be to write the options in another language or an embedded
> language realized with Meta-Programming (like boost::spirit) which yields a
> code which is suitable to parse specific options for an application only.
> Is there a project doing that?
Only of recently maximum length of command line on Windows was really
limited (i think its still like 8K). Most things that need all
configuration to be feed from command line and in theory it may be
*long* are therefore safer to pipe that stuff into stdin instead.
These are usually java teams who are in trouble with it thanks to
their insane directory structure.
Markus Raab
ￜￜ Tiib wrote:
> Only of recently maximum length of command line on Windows was really
> limited (i think its still like 8K). Most things that need all
> configuration to be feed from command line and in theory it may be
> *long* are therefore safer to pipe that stuff into stdin instead.
> These are usually java teams who are in trouble with it thanks to
> their insane directory structure.
With long command line options I mean --input-filter=xml instead of -i xml.
If you hit the maximum length you can still change to short command line
options, both should be supported of course.
It is not really possible to read options from stdin if you read already
data from there.
regards
Markus
--
http://www.markus-raab.org | Unsere Trï¿œume kï¿œnnen wir erst dann
-o) | verwirklichen, wenn wir uns entschlieï¿œen,
Kernel 2.6.24-1-a /\ | daraus zu erwachen. -- Josephine Baker
red floyd
> Hi!
>
> I would need a small and specialiced Library for commandline option parsing.
> It must be BSD licenced (not GPL/LGPL). It should be header-file only
> and/or very small to be full included in the project.
> Up to now I mainly used getopt_pp, but I can't use it because of the licence
> (its a BSD licenced project).
So which is it? You want a BSD licensed lib, but you can't use
getopt_pp
*because* it is BSD licensed?
I think that what you need to do is figure out your requirements and
ask again.
Markus Raab
red floyd wrote:
> So which is it? ï¿œYou want a BSD licensed lib, but you can't use
> getopt_pp
> *because* it is BSD licensed?
The getopt parser needs to be compatible to a BSD licenced project, so ok
are: BSD or public domain.
getopt_pp is GPL, so it is not ok.
Sorry for the unclear statement.
regards
Markus
--
http://www.markus-raab.org | Gegen Demokraten helfen nur Soldaten. --
-o) | G. v. Merckel, Fï¿œnfte Zunft, 1848
Rui Maciel
> Hi!
>
> I would need a small and specialiced Library for commandline option
> parsing. It must be BSD licenced (not GPL/LGPL). It should be header-file
> only and/or very small to be full included in the project.
>
> It should not handle Environment, Configuration files or similar, please
> option parsing only. (So Boost::Program_options sounds like overkill for
> me)
>
> But it should also handle long options well.
>
> Up to now I mainly used getopt_pp, but I can't use it because of the
> licence (its a BSD licenced project). The streaming API is really easy.
> Another approach would be to write the options in another language or an
> embedded language realized with Meta-Programming (like boost::spirit)
> which yields a code which is suitable to parse specific options for an
> application only. Is there a project doing that?
Why don't you write a parser for your command line options?
Rui Maciel
Juha Nieminen
> Why don't you write a parser for your command line options?
Especially since command-line parsing isn't really one of the most
complex tasks in existence. This can be done in most cases rather
trivially with code like this:
int main(int argc, char* argv[])
{
for(int argInd = 1; argInd < argc; ++argInd)
{
if(std::strcmp(argv[argInd], "-option1") == 0)
option1 = true;
else if(std::strcmp(argv[argInd], "-option2") == 0)
option2 = true;
else if(std::strcmp(argv[argInd], "-o") == 0)
{
if(++argInd < argc)
outputFileName = argv[argInd];
else
std::cerr << "Expecting file name after -o\n";
}
// and so on...
}
}
Of if you want to do it in a more C++'ish way (and don't care about the
slight speed/memory overhead):
int main(int argc, char* argv[])
{
std::vector<std::string> args(argv+1, argv+argc);
for(size_t i = 0; i < args.size(); ++)
{
if(args[i] == "-option1") option1 = true;
// and so on...
}
}
The only rational place where you may need to use an actual command line
parser module is if it has some default command line options which you want
to support in more than one program (eg. for an entire suite of programs).
Martijn van Buul
> Hi!
>
> I would need a small and specialiced Library for commandline option parsing.
> It must be BSD licenced (not GPL/LGPL). It should be header-file only
> and/or very small to be full included in the project.
What's wrong with using getopt (the C call from POSIX) or even getopt_long ?
It's most likely already available in your runtime library, and it's not that
hard to use.
All getopt_pp does is wrap it in a C++ wrapper which is neither much more
convenient, nor inherently more safe.
--
Martijn van Buul - pi...@dohd.org
James Kanze
> Rui Maciel <rui.mac...@gmail.com> wrote:
> > Why don't you write a parser for your command line options?
> Especially since command-line parsing isn't really one of the
> most complex tasks in existence. This can be done in most
> cases rather trivially with code like this:
> int main(int argc, char* argv[])
> {
> for(int argInd = 1; argInd < argc; ++argInd)
> {
> if(std::strcmp(argv[argInd], "-option1") == 0)
> option1 = true;
> else if(std::strcmp(argv[argInd], "-option2") == 0)
> option2 = true;
> else if(std::strcmp(argv[argInd], "-o") == 0)
> {
> if(++argInd < argc)
> outputFileName = argv[argInd];
> else
> std::cerr << "Expecting file name after -o\n";
> }
> // and so on...
> }
> }
The problem with this is that if you want to add an option to
control some local functionning, you have to go back and edit
main.
Over a long period of time, I've developped a generalized means
of handling options, where it is sufficient to declare the
option as a variable with static lifetime for it to be taken
into effect (and if it is a boolean option, it auto-converts to
bool, and a numeric option auto-converts to int, so you can use
them directly).
Such a system isn't exactly light-weight, at least if you keep
all the variants I've needed at one time or another. But once
you've got it, it's easy to add an option at anytime, just be
declaring a variable.
> Of if you want to do it in a more C++'ish way (and don't care
> about the slight speed/memory overhead):
Have you ever heard of a program where processing the command
line was a bottleneck? You only do it once.
--
James Kanze
Markus Raab
Martijn van Buul wrote:
> What's wrong with using getopt (the C call from POSIX) or even getopt_long
> ? It's most likely already available in your runtime library, and it's not
> that hard to use.
The while() loop with a long switch statement is not what I would call a
desireable programming style.
The program I am currently replacing used getopt_long. It was a complete
mess, with global side effects and a switch statement over 72 lines.
Of course it is not only getopt_long fault.
> All getopt_pp does is wrap it in a C++ wrapper which is neither much more
> convenient, nor inherently more safe.
getopt_long may be only as safe if you check and convert all your values to
the desired type correctly.
regards
Markus
--
http://www.markus-raab.org | Wissenschaft ist wie Sex ? manchmal kommt
-o) | etwas Nï¿œtzliches dabei heraus, aber das
Kernel 2.6.24-1-a /\ | ist nicht der Grund, warum wir es
on a x86_64 _\_v | betreiben. -- Richard P. Feynman
Markus Raab
Juha Nieminen wrote:
> The only rational place where you may need to use an actual command line
> parser module is if it has some default command line options which you
> want to support in more than one program (eg. for an entire suite of
> programs).
Actually it is a large suite of about 10-20 programs. But most arguments
always differ. Any hints?
regards
Markus
--
http://www.markus-raab.org | Alter schï¿œtzt vor Torheit nicht. --
-o) | Sprichwort nach W. Shakespeare
Markus Raab
James Kanze wrote:
> Over a long period of time, I've developped a generalized means
> of handling options, where it is sufficient to declare the
> option as a variable with static lifetime for it to be taken
> into effect (and if it is a boolean option, it auto-converts to
> bool, and a numeric option auto-converts to int, so you can use
> them directly).
>
> Such a system isn't exactly light-weight, at least if you keep
> all the variants I've needed at one time or another. ï¿œBut once
> you've got it, it's easy to add an option at anytime, just be
> declaring a variable.
Sounds interesting, do you have more information about it?
Is the code for one project only?
>> Of if you want to do it in a more C++'ish way (and don't care
>> about the slight speed/memory overhead):
>
> Have you ever heard of a program where processing the command
> line was a bottleneck? ï¿œYou only do it once.
Last week I heard that the unpaper tool has a incredible slow commandline
parsing. It somewhat iterates over every argument for every argument or
something like that. But nevertheless it is still not a bottleneck... (But
noticeable slow on older computers)
regards
Markus
--
http://www.markus-raab.org | Der Weg ist das Ziel -- Sprichwort
-o) |
James Kanze
> James Kanze wrote:
> > Over a long period of time, I've developped a generalized means
> > of handling options, where it is sufficient to declare the
> > option as a variable with static lifetime for it to be taken
> > into effect (and if it is a boolean option, it auto-converts to
> > bool, and a numeric option auto-converts to int, so you can use
> > them directly).
> > Such a system isn't exactly light-weight, at least if you keep
> > all the variants I've needed at one time or another. But once
> > you've got it, it's easy to add an option at anytime, just be
> > declaring a variable.
> Sounds interesting, do you have more information about it?
> Is the code for one project only?
Originally, it was for a single project. I then brought it into
another, and another (each time adding something that particular
project needed---that's why it definitely isn't light
weight:-)). A reasonably recent version is available at my web
site (kanze.james.neuf.fr), albeit rather embedded in a lot of
other stuff, which makes it difficult to use without
incorporating all of my library, which might not be everyone's
cup of tea.
> >> Of if you want to do it in a more C++'ish way (and don't care
> >> about the slight speed/memory overhead):
> > Have you ever heard of a program where processing the command
> > line was a bottleneck? You only do it once.
> Last week I heard that the unpaper tool has a incredible slow
> commandline parsing. It somewhat iterates over every argument
> for every argument or something like that. But nevertheless it
> is still not a bottleneck... (But noticeable slow on older
> computers)
How may arguments do you pass to it on the command line. It
sounds O(n^2), but I would expect that n is still pretty small.
My command line parser is definitly not optimized. I never saw
any need for it.
--
James Kanze
Öö Tiib
> Hi!
>
> Juha Nieminen wrote:
> > The only rational place where you may need to use an actual command line
> > parser module is if it has some default command line options which you
> > want to support in more than one program (eg. for an entire suite of
> > programs).
>
> Actually it is a large suite of about 10-20 programs. But most arguments
> always differ. Any hints?
Sounds like what you need is still boost.program_options.
For refactoring something it is flexible enough. With other things you
probably end up with such a mess of switch-case-exception-oddity
command line parsing.