Jq: Errors on Keys with Hyphens

Created on 20 May 2016 · 6Comments · Source: stedolan/jq

While developing some shell tools I decided to try jq which seemed to work beautifully until I tried

$ jq '.devDependencies.ember-cli' package.json
jq: error: cli/0 is not defined at <top-level>, line 1:
.devDependencies.ember-cli                       
jq: 1 compile error

After further testing I found that jq was fine as long as I didn't try to directly access a key that had a hyphen in it. If I went to just display '.devDependencies' it would list everything fine. And I could target any key within the '.devDependencies' object that didn't have a hyphen in it's name.

This is on an OS X El Capitan 10.11.5 system with jq-1.5 installed via Homebrew yesterday.

Source

runeimp

Most helpful comment

It's not a workaround, but a parsing problem. The jq language gives higher
preference to the minus operator than it does a dotted path.

The .[something] syntax is preferred because it allows for complex
expressions.

That said, for simple lookups, we do prefer .this.that.

Also, if you can't guarantee your code will run on jq1.5, the
.["that-thing"] syntax is guaranteed to be supported.

On Fri, May 20, 2016, 15:53 RuneImp [email protected] wrote:

Hm, I'm glad there is a workaround. But why is that even necessary? Is the
JSON being converted to JavaScript at some point? JSON keys are just
strings and shouldn't care about any characters except double-quotes,
backslashes, and control codes according to JSON.org.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/stedolan/jq/issues/1156#issuecomment-220703032

wtlangford on 20 May 2016

👍2

All 6 comments

With jq 1.5, you can either enclose the field name in quotation marks ( ."field-name") or use the more portable technique illustrated by: .["field-name"]

This is now covered in the manual, and elsewhere.

pkoppstein on 20 May 2016

👍1

Hm, I'm glad there is a workaround. But why is that even necessary? Is the JSON being converted to JavaScript at some point? JSON keys are just strings and shouldn't care about any characters except double-quotes, backslashes, and control codes according to JSON.org.

runeimp on 20 May 2016

👎1

It's not a workaround, but a parsing problem. The jq language gives higher
preference to the minus operator than it does a dotted path.

The .[something] syntax is preferred because it allows for complex
expressions.

That said, for simple lookups, we do prefer .this.that.

Also, if you can't guarantee your code will run on jq1.5, the
.["that-thing"] syntax is guaranteed to be supported.

On Fri, May 20, 2016, 15:53 RuneImp [email protected] wrote:

Hm, I'm glad there is a workaround. But why is that even necessary? Is the
JSON being converted to JavaScript at some point? JSON keys are just
strings and shouldn't care about any characters except double-quotes,
backslashes, and control codes according to JSON.org.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/stedolan/jq/issues/1156#issuecomment-220703032

wtlangford on 20 May 2016

👍2

Wow, looked into the manual. Didn't realize by the homepage and tutorial all the potential of jq. Even cooler than I thought it was before. Very nice! 😃

runeimp on 20 May 2016

@wtlangford - Glad to see you back in action.

On Mar 15 Nico wrote "I'll probably not get around to doing a release for a bit longer yet for lack of time."(#1066). He has evidently continued to be too busy to do so. Since a new release is sorely needed, if only because of fixes to problems affecting Windows users (#1145, #1072, #1066 ...), I was wondering whether you'd be in a position to create one.

pkoppstein on 20 May 2016

The issue still persists in the Windows 32 bit 1.5 release. .["field-name"] throws an error (I didn't test the 64 bit version).