path/1 as a simpler eval just for path expressions

[crazygolem]

When calling jq from a shell script, I find that parameterizing paths that need to get evaluated is not very ergonomic:

1. The quick and dirty solution is to quote your shell variable in the jq program
2. A better solution is to use getpath/1, setpath/2 and delpath/1 and pass the PATHS array to jq with --argjson, but writing paths as a JSON array gets quickly boring
3. You can improve on the previous solution by passing a path expression as a string with --arg and somehow parsing it into a PATHS array, e.g.:
   • As suggested in #1493 with $path | split(".")[1:], but this only accepts a limited subset of all path expressions supported by jq
   • By implementing a more comprehensive parser, but it can only be done for exact match path expressions (and has to track separately jq updates such as 1.7 that allowed a dot between chained indexes)

In the long term, an eval function (#384) would add built-in support for evaluating paths passed as strings, but without going that far, would it be possible to make a variant of path/1 that accepts the path expression as a string?

I suppose that limiting the dynamic evaluation to just paths instead of whole jq programs makes it possible to sidestep the issues mentioned for eval (e.g. no need to handle contexts and whatnot), in particular since the functions simply turns the string into a PATHS array without having to insert it into the evaluation pipeline.
Or is there a limitation in the current implementation that makes it impossible to evaluate paths dynamically without the machinery that eval would need?

[wader]

Hi, that would be nice. And yes i think a path/1 function that takes a string would have to define a path expression subset it supports as standard path expression can contain arbitrarily complex jq programs, ex .a[range(5) | select(.%2 == 0)], so maybe only literals, index, slicing, iteration, , etc? take inspiration from JSONPath and similar standards? i don't know for sure but what i've know/seen it's not a small task to implement a limited eval.

If you want eval today in jq there is jqjq and fq but both has their caveats, jqjq is slow, has bugs, subset of jq, horrible error handling etc, fq uses gojq which differ from jq in some areas.

$ jq --arg p '.a[range(5) | select(.%2==0)]' -L . 'include "jqjq"; eval($p)' <<< '{"a": [0,1,2,3,4]}'
0
2
4
$ fq --arg p '.a[range(5) | select(.%2==0)]' 'eval($p)' <<< '{"a": [0,1,2,3,4]}'
0
2
4
# also has expr_to_path/path_to_expr
$ fq -n '".a" | expr_to_path | path_to_expr'
".a"

BTW thanks for gist link! nice