jq
jq copied to clipboard
Return error for string literal beginning with single quote
Summary
In order for a string literal to be valid in JSON, the value must be surrounded by double quotes. This PR updates the literal validation function to return an error message when the literal begins with a single quote.
I'm not sure if this is the best solution since the line/col that gets reported is at the end of the literal and might be confusing. Another possible solution would be to mark the single quote character as invalid in the classify function. This would give the exact line/col where the invalid string begins, but I'm not sure if there would be other consequences to doing this. It appears that reporting the position after an invalid literal is seen elsewhere e.g. echo '{"foo":flase}' | jq.
Testing
Run the command echo "{'foo': 1}" | jq and ensure the output mentions an invalid string literal. Compare this to the dev version of jq which mentions an invalid numeric literal.
Closes #501
Probably good to add a test case for this to tests/jq.test:
try fromjson catch .
"{'a': 123}"
"Invalid numeric literal at line 1, column 5 (while parsing '{'a': 123}')"
(but with updated error message)
About other error cases: I wonder if the could somehow check the first character to know if this if something resembling a number so that we could distinguish between invalid number and other invalid things?
Probably good to add a test case for this to
tests/jq.test:
Of course! I got excited and committed before looking into how tests were handled :facepalm:
About other error cases: I wonder if the could somehow check the first character to know if this if something resembling a number so that we could distinguish between invalid number and other invalid things?
Not sure I follow. Isn't this what the parser already does around the code I added?
Of course! I got excited and committed before looking into how tests were handled 🤦
No worries :)
About other error cases: I wonder if the could somehow check the first character to know if this if something resembling a number so that we could distinguish between invalid number and other invalid things?
Not sure I follow. Isn't this what the parser already does around the code I added?
Haven't look close att the current code but it seems like the clumps together a lots of different invalid jsons texts into "Invalid numeric literal" some i think we could probably split up into more user friendly errors and suggestions:
Did a script to try different strings:
$ for i in true false nan ident truea falsea nana aa1 1aa + - / "&" "*" '(' "'aa'"; do echo "$i:\t$(jq 2>&1 <<< "$i")"; done
true: true
false: false
nan: null
ident: jq: parse error: Invalid numeric literal at line 2, column 0
truea: jq: parse error: Invalid literal at line 2, column 0
falsea: jq: parse error: Invalid literal at line 2, column 0
nana: jq: parse error: Invalid literal at line 2, column 0
aa1: jq: parse error: Invalid numeric literal at line 2, column 0
1aa: jq: parse error: Invalid numeric literal at line 2, column 0
+: jq: parse error: Invalid numeric literal at line 2, column 0
-: jq: parse error: Invalid numeric literal at line 2, column 0
/: jq: parse error: Invalid numeric literal at line 2, column 0
&: jq: parse error: Invalid numeric literal at line 2, column 0
*: jq: parse error: Invalid numeric literal at line 2, column 0
(: jq: parse error: Invalid numeric literal at line 2, column 0
'aa': jq: parse error: Invalid numeric literal at line 2, column 0
Sidenote:
No idea what is going on with -:
$ echo - | jq
$
# weirdly gojq behaves the same
$ echo - | gojq
$
Recognized as echo command option.
Recognized as echo command option.
Thanks 🤦
LGTM if you add the test
Hey all, sorry for the delay. It's the busy part of the year. I went ahead and updated the error message, checked for a few more invalid literals, and added some tests. Let me know if there are any more changes you would like to see.