Re: [help-gengetopt] cmdline_file_save accepts file handler instead

[Lorenzo Bettini]

Papp Gyozo (VBuster) wrote:
> Hi,
>
> I debugged it but up to now I don't know what is wrong with.
> I made make clean && make check in the gengetopt 2.21 tests directory, log 
> attached.
>
> I found only one FAILED test: test_conf_parser_err_string.sh and not the one 
> Lorenzo mentioned below:

yes this makes sense since the previous patch, as you said in the 
previous email, was removing a vital instruction, so also the correct 
conf files were considered wrong.

> > > concerning the patch for config file, my tests for config file parsers
> > fail:
> > > test_conf_parser:./test_conf.conf:7: malformed string in configuration
> > file
> > > FAIL: test_conf_parser.sh
> > > could you please check this?
>
> test_conf_parser_err_string.sh contains two test cases (attached):
> - first the test_conf_parser sample is executed on test_conf_err_string.conf
> - if it passes the previous test(!) then it will be tested against 
> test_conf_err_string2.conf
>
> Each test_conf file contains malformed strings.
>
> I suspect that the second testcase had never ran before. Before applying my 
> patch gengetopt rejected lines similar to this one from 
> test_conf_err_string.conf

actually, if you look at the .sh test

if $* ./test_conf_parser -r "bar" -a 100 -c 
@srcdir@/test_conf_err_string.conf; then
        false;
else
        if $* ./test_conf_parser -r "bar" -a 100 -c 
@srcdir@/test_conf_err_string2.conf; then
              false;
        else
              true;
        fi
fi

you see that the intent of the first if is to make sure that the call 
actually fails; and then checks that also the second call fails (the 
second call was always executed, if you take a look at test.out 
containing the output of all the tests).  Thus the test succeeds if both 
calls fail.

> multi-string = mal"formed"
>
> My patch accepts this argument and treated as a valid string value as is 
> (mal"formed") for the option 'multi-string'. That's why the next never executed 
> testcase will fire, too, but it contains an invalid string value:
>
> multi-string = "unterminated
>
> I really hope I shed some light now. Is there any other volunteer to confirm my 
> experience?

now, with your patch mal"formed" is not considered a malformed string 
anymore thus the first call does not fail, and the .sh returns false, 
that why the test fails.

As far as I understand, now only

"foo

is considered a bad string, while foo" would be considered as the string 
foo" right?

so I'm wondering, does it really make sense to consider "foo still a 
malformed string?

Actually, I'm still reluctant in considering mal"formed" a good argument 
since it is not consistent with command line arguments, where " must be 
escaped...

can we discuss a little bit on this?

thanks
        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