<f00b4r0>
i don't even understand how the result is valid uci
<f00b4r0>
how is the part after the closing quote interpreted?
<jow>
it's just the terminal rendering an embedded carriage return
<f00b4r0>
sure, ignoring the cr, we have: option test 'foo'ar123
<f00b4r0>
how is that valid?
<jow>
it actually is option test 'foo\nbar\t123\r'
<f00b4r0>
oh
<f00b4r0>
gee
<jow>
(transliterated, the parser does not understand the '\r' escape sequence
<f00b4r0>
i'm not sure why we allow something like this but I guess there's a very good reason :)
<jow>
single quotes strings are parsed naively
<jow>
they may contain anything expect another single quote (which terminates it) and null bytes
<jow>
anything includes the entire ascii byte range (sans \0 and <'>)
<jow>
uci also supports implicit concatenation of literals like the shell does
<jow>
so option test 'foo'"'"'bar' is <foo'bar>
<jow>
or 'foo'\''bar'
<jow>
and option test 'foo'"bar" would result in <foobar>
<jow>
etc.
<f00b4r0>
ok
<f00b4r0>
my parser needs a bit more work then
<jow>
there must be no (unescaped) space between consecutive literals though
<jow>
so option test 'foo' 'bar' is a syntax error
<f00b4r0>
makes sense
<jow>
while option test 'foo'\ 'bar' results in <foo bar>
<jow>
and
<jow>
option test 'foo'\
<jow>
'bar'
<jow>
in <foo\nbar>
<f00b4r0>
why did you have to make it so hard ;P
<jow>
oh, invariant
<jow>
'foo'\
<jow>
'bar'
<jow>
is not <foo\nbar> but <foobar>
<f00b4r0>
what?!
<jow>
this looks like an undefined implementation details of the parser logic though
<jow>
*detail
<jow>
one that does not really make sense imho
<jow>
likely a bug
<f00b4r0>
hmm. I think I'll start with the basic line-by-line stuff that covers 99.9% of the cases
<jow>
it's important to know that the uci parser does not work line by line (at least not in the sense that it reads an entire line into a bugger and then tries to split it)
<jow>
*buffer
<f00b4r0>
since you completely shattered my dream of having something nice and simple :)
<jow>
it rather treats the file like a token stream, asstering newline in various contexts
<jow>
*asserting
<jow>
damn, bad typing today
<jow>
you should probably model your parser in a similar way
minimal has joined #openwrt-devel
<f00b4r0>
that's roughly what I've done so far
<f00b4r0>
i was under the impression that newline terminated a statement (outside of a quoted string then)
rz has quit [Ping timeout: 480 seconds]
<f00b4r0>
I think I'm not very far from what you described, save for the "implementation detail" which I think I'll just ignore
<f00b4r0>
have to run for an errand, bbiab. Thanks for the help!
<jow>
the general logic is simple, for barewords and double quoted strings, the backslash escapes the next character
<jow>
regardless of what it is
<jow>
but some characters (character sequences) following a backslash are silently discarded (along with the backslash itself)
<f00b4r0>
that's fine, I'm not processing the actual content. I'm merely checking the syntax is valid, so I don't need to bother too much with escape sequences (except when they escape what would otherwise terminate the token)
<Piraty>
what is the process / policy of commits to be cherry-picked onto a releaes branch? for example 80b2288ea3234958e78761cc4720c03d4072d830 or 79e9ce354efc03859fea288d4131b8fa0cca1b3a
<Piraty>
did nobody care yet? are those commits not fit to be backported/cherry-picked ?