RE: [help-gengetopt] Re: Gengetopt V 2.20 String Parser/Multiple Parsers problems with blank spaces around numerics and order of the arguments.

[Nikolay Yevik]

Lorenzo,

This issue appears to be the root of the both problems.

Thank you for clarifying this.




-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Lorenzo Bettini
Sent: Wednesday, August 01, 2007 9:12 AM
To: Nikolay Yevik; Users list for gengetopt
Subject: [help-gengetopt] Re: Gengetopt V 2.20 String Parser/Multiple
Parsers problems with blank spaces around numerics and order of the
arguments.

Nikolay Yevik wrote:
> 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.
> 
>  
> 
>    2. 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.

Hi Nikolay

I think the problem is actually in the client.c code: when you read a 
line from the file with fgets you also get the \n at the end, thus when 
you get to the line

-c 0xFFDD

strtol tries to convert to a number this string 0xFFDD\n which is not a 
valid number.

I could also clean the \n in the generated parser code, but I think it 
would not be right, since the string parser expects a valid command line

(i.e., without the terminating \n newline char).  However, concerning 
this point I'd like to hear from other people on the list.

If you modify your client code as in the attached file, you won't have 
this problem; the modified part is as follows (notice that I also avoid 
empty strings, just to be safe):

52a53,60
 >
 >                 /* avoid empty strings */
 >                 if (!strlen(commandLine)) continue;
 >
 >                 /* make sure to remove the \n char */
 >                 if (commandLine[strlen(commandLine)-1] == '\n')
 >                   commandLine[strlen(commandLine)-1] = '\0';
 >

as for the other problem, i.e., the order of arguments, could you please

provide an example of this problem?  I didn't experience this, but I'm 
pretty sure it was due to the above \n issue.

I hope to hear from you soon!

cheers
        Lorenzo

-- 
Lorenzo Bettini, PhD in Computer Science, DSI, Univ. di Firenze
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net

----------------------------------------------------------------------
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.