jq
jq copied to clipboard
jqlang
"Invalid Numeric Literal" on colon following a single-quoted string (incorrect parser error message)
EDIT (20150416): I KNOW IT'S INVALID JSON. THE BUG IS ABOUT THE NONSENSICAL ERROR MESSAGE
I get this from absent-mindedly and incorrectly using single-quotes:
$ echo "{'foo':'bar'}" | jq .foo
parse error: Invalid numeric literal at line 1, column 7
This is under 1.3. Trying to reproduce under 1.4, but after 5 minutes of trying to build from source I'm just going to submit this and move on.
@bartgrantham - Later versions produce the same (confusing) error message, e.g.
$ jq --version
jq-1.4-100-g0f89270
$ echo "{'foo':'bar'}" | jq .foo
parse error: Invalid numeric literal at line 1, column 7
The simplest demonstration of the issue may be:
echo "'" | jq .
parse error: Invalid numeric literal at line 2, column 0
This is a very long-standing issue with the JSON parser (not the parser for jq code, but the parser for JSON input). Essentially, the logic is: is it an array? nope. is it an object? nope. (...) well, it must be a number. parse error on a number.
I suppose the fix is probably to choose a different error message if the invalid character is not in [0-9+-].
according to json.org a string is to be "wrapped in double quotes"
so, use double and escape from echo's
$ echo "{\"foo\":\"bar\"}" | jq .foo
"bar"
We've found the best practice to be single quotes around json data and also your jq program.
$ echo '{"foo":"bar"}' | jq '.foo'
It allows you to use double quotes without escaping and prevents the shell from attempting to process them.
Also, 1.4 should exist as precompiled binaries on the website and is also in most package manager repositories.
On Sun, Nov 23, 2014, 11:44 Jacob Berger [email protected] wrote:
according to json.org http://www.json.org/ a string is to be "wrapped in double quotes"
so, use double and escape from echo's
$ echo "{"foo":"bar"}" | jq .foo
"bar"
— Reply to this email directly or view it on GitHub https://github.com/stedolan/jq/issues/501#issuecomment-64124363.
@bergerjac, @wtlangford - I know single-quotes for strings are wrong, I mentioned at the beginning that I "absent-mindedly and incorrectly" used them. The issue is that the error produced is cryptic.
Good point. I might look into a better error for the parser, but the issue with that is the parser does "is it an object?" "Is it an array?" "Is it a string?" "Must be a number!". The current master gives a slightly better error, but I've also seen it fail an assertion, depending on what I pass in.
On Sun, Nov 23, 2014, 12:29 Bart Grantham [email protected] wrote:
@bergerjac https://github.com/bergerjac, @wtlangford https://github.com/wtlangford - I know single-quotes for strings are wrong, I mentioned at the beginning that I "absent-mindedly and incorrectly" used them. The issue is that the error produced is cryptic.
— Reply to this email directly or view it on GitHub https://github.com/stedolan/jq/issues/501#issuecomment-64126198.
Of course, the Windows cmd.exe isn't... as advanced as the typical Unix shell.
We really need something like a REPL to make Windows jq users happy...
Ok, I have a big json dump (sql export) that gives this error. Any work-arounds to make it work with jq until this error is fixed?
@delip - Since you have a big JSON dump, you are presumably reading it in as a file. In that case, from what you write, it would seem that the error message you see will give the line and column numbers of the invalid JSON. Thus it is unclear to me what kind of work-around you would like. That is, if your big json dump is invalid JSON, the simplest thing to do might be to fix it.
@delip You have to give us an example. @bartgrantham That's not JSON. JSON uses double-quotes -not single-quotes- for strings.
If the request is to have more sensible error messages from the JSON parser, that's another story.
@nicowilliams, I know! I said it in the opening post that it was "incorrect", the bug is about the error messages being misleading. I even wrote it again in this thread, barely a page up from your comment:
I know single-quotes for strings are wrong, I mentioned at the beginning that I "absent-mindedly and incorrectly" used them. The issue is that the error produced is cryptic.
PLS use cat /tmp/data.log | jq . Do not use grep "KEY" /tmp/data.log | jq .
Your pasted output from the preliminary command works for me when I pipe it
into your jq command. I suspect /tmp/read may be doing something
different when it's piped into jq? Try echo "42fdfc072112624f" | /tmp/read | tee test.out and see what's in test.out?
On Mon, Jun 11, 2018 at 9:55 AM mh-cbon [email protected] wrote:
hey guys, i m facing the same issue, but i don t understand.
Please take a look
$ echo "42fdfc072112624f" | /tmp/read | jq -r '.["42fdfc072112624f"]' parse error: Invalid numeric literal at line 1, column 9
where preliminary command output is
$ echo "42fdfc072112624f" | /tmp/read { "42fdfc072112624f": "65465Uv38ByGCZU1WP18P" }
????????
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stedolan/jq/issues/501#issuecomment-396251615, or mute the thread https://github.com/notifications/unsubscribe-auth/ADQ4VyStuKNUas8FzoXl8W28hHv_YT0_ks5t7nbSgaJpZM4CQUNi .
This error came up for me using jq . < output-json.sh but disappeared when I did output-json.sh | jq .. I don't know why but maybe it will help someone (googling initially led me here).
@simesy That's because you're sending the content of output-json.sh itself into jq, not the output of running that command. It's the same as jq . < somedata.json.
If you really want to redirect the output of your shell script into jq with input redirection, you can do it in bash with jq . <(output-json.sh), but IMHO the pipe syntax you're using is much clearer to read.
whoo use curl then parse to jq like 'curl http://req.url/get | jq .' then get error like on top. just add -s on curl, like ' curl -s http://req.url/get | jq .' and everything be alright
Curious why this was closed? v1.6 still outputs the same nonsense error if the input is not valid JSON.
$ printf '%s' " ' " | jq .
parse error: Invalid numeric literal at EOF at line 1, column 3
$ echo $?
4
@chet-manley yeah, I think maybe @wtlangford closed this by accident thinking it was a different bug report? This should be re-opened IMO.
% jq --version
jq-1.6
% echo "{'test': 'test'}" | jq
parse error: Invalid numeric literal at line 1, column 8
@stedolan @wtlangford Any guidance as to why this was closed without addressing the issue?
@chet-manley if the file is using single quote, then it's not actually json format. A json payload must use quotation marks. This is based on the actual standard as per RFC 8259 (https://datatracker.ietf.org/doc/rfc8259)
I think it's still a good feature to have it support single quotes.
PS: The mistake that our engineer was doing is not specifying the file/format type in his request. So he was getting single quotes. As soon as he started specifying this, he got back quotations in his payloads.
@nkhoury-payments This issue is not about single quotes vs. double quotes. This issue is about the misleading error message "Invalid numeric literal" when the error is the use of a single quote. That's what @chet-manley was referring to, and what this issue is about.
Incedentally, it would be a huge mistake for jq to start supporting non-standard single quotes in JSON.
@bartgrantham thanks for the clarification about the error message.
I install jq from brew on macOS. And I copied and pasted jq tutorial this text
jq '.[0] | {message: .commit.message, name: .commit.committer.name}'
on iTerm. But this command not finished. I think this is waiting ; then it occured
parse error: Invalid numeric literal at line 2, column 0
I don't think you mayby understand what i say. because i'm not good at English. Thx
jq processes the standard input
curl -s 'https://api.github.com/repos/stedolan/jq/commits?per_page=5' | jq '.[0] | {message: .commit.message, name: .commit.committer.name}'
