Re: cmdline_file_save accepts file handler instead
Lorenzo Bettini <[email protected]> Sat, 20 Oct 2007 18:58:04 +0200
| Newsgroups | gmane.comp.gnu.gengetopt.general |
|---|---|
| Message-ID | <[email protected]> |
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