help-gengetopt
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[help-gengetopt] Gengetopt V 2.20 String Parser/Multiple Parsers problem


From: Nikolay Yevik
Subject: [help-gengetopt] Gengetopt V 2.20 String Parser/Multiple Parsers problems with blank spaces around numerics and order of the arguments.
Date: Mon, 30 Jul 2007 17:00:59 -0500

Greetings,

 

Would be much obliged if anybody could help me with the following problems I see with gengetopt 2.20 (latest)  

as well as previous versions (tried down to 2.17) using string parser.

 

OS: Linux (tested Open SUSE Linux 10.2 and Mandriva 2006 and 2007 (0x86 and 0x86_64) )

Gengetopt V 2.20 (latest) compiled with GCC 4.1.x.

 

I wrote a client that must take arguments from both CLI as well as from a file.

 

When parameters are passed on CLI everything works fine (using cmdline_parser() function).

For example:

./client –v –c 0x1234 –print

 

When using cmdline_parser_string() to read flags from a file line by line I start seeing strange behavior:

  1. Parser becomes very picky about white/ blank spaces at the end or beginning of each line and especially around numeric values.

 

  1. Parser becomes picky about the order of arguments/flags. Whereas for CLI parser it did not matter in what order I passed the flags, it matters for the string parser.

 

 

 

I traced the first  problem down to the generated cmdline_parser_internal() function  that has the following code for each and every numeric option/argument  passed to the command:

if (!(stop_char && *stop_char == '\0')) {

            fprintf(stderr, "%s: invalid numeric value: %s\n", argv[0], optarg);

            goto failure;

 }

If for every numeric command argument I comment out this generated code in the cmdline.c file generated by gengetopt from my .ggo file I circumvent at least the first problem.

However, this is a rather crude hack and I’d like to understand  the root cause of this problem is.

Is this a bug?

 

I am still trying to find a behavior pattern for the second problem. That is, - why some order of parameters work and the other don’t and why the order should matter at all.

For one thing it appears that it does not like the long options to be the first.

 

I am attaching a test case illustrating the problem.

 

The client can take commands from both command line as well as a file or just from a file.

Example

 

./client –c 0x1234 –f testfile.txt

Or

./client –f testfile.txt

 

 

Any help will be greatly appreciated.

 

 

Respectfully,

 

Nikolay V. Yevik

 

Technical Advisor

Halliburton ESG

 

 

 


This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.

Attachment: testcase.zip
Description: testcase.zip


reply via email to

[Prev in Thread] Current Thread [Next in Thread]