Option to allow for Single-Quoted strings

[JanHoefelmeyer]

Currently, when trying to parse strings using single quotes ', the tool will return a syntax error. This is not according to the JSONPath standard (see here) and also not always what a user might expect, as expressed in https://github.com/PaesslerAG/jsonpath/issues/31, https://github.com/PaesslerAG/jsonpath/issues/23 and https://github.com/PaesslerAG/jsonpath/issues/19.

This seems to be because the tool uses Gval, which supports especially Go-like arbitrary expressions using go's text/scanner package.

Strings in Go are portrayed by double-quotes "..." and as raw-strings `...` . Single-quoted-strings '...' are not known in Go. Instead, they are used to indicate single characters and runes. This means, when the tool encounters single-quotes strings, it will try to parse it as a single character and fail, throwing an error.

Since text/scanner is working correctly within Go context, it's unlikely that they will amend their library to allow single-quoted strings. As such, it's probably easier to modify the tools Gval implementation to allow its scanner to identify and parse single-quotes strings.

Addtionally, the strconv.Unquote functionality used by this tool also is based on Go, and as such will not accept single-quoted strings. As such, the parseString-method could be adjusted as well, so that it transforms single-quoted strings into double-quoted strings, allowing them to be parsed.

If these changes are made, jsonpath is able to handle single-quotes (although e.g. unit tests would've to be adjusted, since they already assume failure at single quotes). These changes could be made optional as to not disrupt potential workflows that already depend on jsonpath not evaluating single quoted strings.

Would this, in your opinion, be a sensible way to solve the issue?

[mhengl]

Hi @JanHoefelmeyer, after discussing the topic with a colleague, your suggestion sounds reasonable. Can you provide a pull request to both repositories for this?

[bernhardreiter]

@mhengl did you or your colleagues had a chance to look at the implementations at https://github.com/PaesslerAG/gval/pull/98 and #39 ?