testbench: field_descent_with_invalid_ruledef.sh fails when run manually

[rgerhards]

There is something strange with this test. It works perfectly when run as part of make check but it fails as follows if run interactively:

============================================================================
Testsuite summary for liblognorm 1.1.2.master
============================================================================
# TOTAL: 27
# PASS:  27
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
make[2]: se sale del directorio «/home/rger/proj/liblognorm/tests»
make[1]: se sale del directorio «/home/rger/proj/liblognorm/tests»
rger@ubuntu1404esp:~/proj/liblognorm/tests$ !./fi
./field_descent_with_invalid_ruledef.sh 
===============================================================================
[field_descent_with_invalid_ruledef.sh]: test for descent based parsing field, with invalid ruledef
Using valgrind: no
Out:
{ "originalmsg": "10.20.30.40 foo", "unparsed-data": "10.20.30.40 foo" }
Out:
{ "originalmsg": "10.20.30.40 foo", "unparsed-data": "10.20.30.40 foo" }
Out:
{ "originalmsg": "10.20.30.40 foo", "unparsed-data": "10.20.30.40 foo" }
Out:
{ "originalmsg": "10.20.30.40 foo", "unparsed-data": "10.20.30.40 foo" }
Out:
{ "originalmsg": "10.20.30.40 foo", "unparsed-data": "10.20.30.40 foo" }
Out:
{ "originalmsg": "10.20.30.40 foo", "unparsed-data": "10.20.30.40 foo" }
Out:
{ "originalmsg": "10.20.30.40 foo", "unparsed-data": "10.20.30.40 foo" }
Out:
{ "originalmsg": "10.20.30.40 foo", "unparsed-data": "10.20.30.40 foo" }
Out:
{ "originalmsg": "10.20.30.40 foo", "unparsed-data": "10.20.30.40 foo" }
JSONs weren't equal. 
    Expected: 
        { "net": { "tail": "foo", "ip_addr": "10.20.30.40" } }
    Actual: 
        { "originalmsg": "10.20.30.40 foo", "unparsed-data": "10.20.30.40 foo" }

Checked with commit e27749e429de931d6258c57360e95239a5a85e59 which does not include the somewhat controversal patch for issue #57.

[rgerhards]

Note: this will probably be removed in v2 in any case. So it's questionable if it is worth spending time on it.