-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments in Json #402
Comments
No. JSON is specified by RFC7159, and it doesn't have a format for
as that way we could at least logically preserve comments. But as it I have needed this in the past, so what I tend to do is this:
or
No comments in arrays, nor at the top-level in any case. C'est la vie. |
More generally, it would be great if there could be a "--javascript" switch that would authorize jq to accept Javascript-style JSON. This would, for example, allow {a: "1"} to be "translated" to {"a": "1"}. |
@pkoppstein My intention is to allow multiple parser types. Ditto |
@nicowilliams wrote:
Please note that the original request was explicitly that they be ignored.
Understood, but don't forget that currently jq is not as strict as the "full stop" would suggest. See e.g. #348 |
@pkoppstein Yeah, I know, but I think that's just unfortunate. I suppose I could add "ignore comments" to the current parser, but I don't really feel up to it. I'm very busy with other things and any cycles I can spare to jq I'd rather use for more deserving things. Even if you send me a PR for that, I think I might not take it, mostly because the parser is a bit messy and I don't want to make it messier. (I tried extending it to support streaming, but that made it much too messy, and that's when I decided on having multiple parsers.) OTOH, a PR for multiple parser types... that'd be nice. I'm thinking of how to integrate that properly with the I/O builtins I'm still baking. |
Also, quite frankly, there's a difference between accepting unescaped control characters and ignoring comments that jq couldn't produce. The latter makes one wonder what the point of comments is. It's much better to use a commenting convention like I described than comments that no parser will/should preserve! Mind you, there are problems with accepting unescaped control characters. I may very well remove that, possibly for just some control characters, possibly for all the ASCII ones -- do not rely on jq's willingness to accept unescaped control characters! |
Regarding the handling of comments in JSON, see https://github.com/stedolan/jq/wiki/FAQ#processing-not-quite-valid-json |
@pkoppstein Thanks! Do you know if that will also work for mongodb generated json ... this typically looks something like this:
|
@vito-c - That of course is, as they put it, "mongodb-extended-json", not JSON. ("http://docs.mongodb.org/master/reference/mongodb-extended-json) MongoDB does provide a utility for producing JSON from a MongoDB instance (but apparently not from a text file):
Details about mongoexport are at: http://docs.mongodb.org/master/reference/program/mongoexport/#bin.mongoexport Here is the URL of a script that purports to convert bson to json: |
To quote the great @pkoppstein,
For example, jq currently accepts strings containing U+0083, which is not valid JSON according to RFC7159. In fact, this is almost exactly the same as the comments issue; both are valid JavaScript but not valid JavaScript Object Notation. It would be reasonable to have a "strict" (or "non-strict") flag. I don't expect jq to output non-strict JSON. But it would be good for it to accept non-strict JSON, as it already does today. |
👍 |
Douglas Crockford explains why he removed comments from JSON in https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr (It's not that they were not put in. They were there. They were removed. They should not be put back.) But, in the last sentence he also gives you the solution.
These posts are becoming a common theme for me. hashicorp/packer#1768 (comment) |
For some lightweight parsing and modifying of jsonc documents I've created jsonc-cli which is just a cli front-end for Microsoft's jsonc-parser. |
If you have #!/bin/bash
node -p 'JSON.stringify(eval(`(${require("fs").readFileSync("'${1}'"||0, "utf-8").toString()})`))'
Then echo '{"foo":42 /*hello*/}' | stripjsonc # => {"foo":42}
# or
cat /tmp/foo.jsonc # { /*hello*/ "foo":7}
stripjsonc /tmp/foo.jsonc # => {"foo":7} |
Is there a way to have jq ignore comments that have been added to the json file:
{
/* People insist on putting comments in data */
"foo": "test",
"bar": "baz"
}
The text was updated successfully, but these errors were encountered: