*TL;DR: With **custom --rpl flag*
<https://gist.github.com/vergenzt/864010adbac64def312190d85607109b>* (also
pasted below), you can use **{[***jq_expr***]}** to insert the shell-quoted
result of passing the input into **jq* <https://jqlang.org>* with the given
***jq_expr***.*
E.g. If each input line is a JSON object, then {[.id]} will insert the
shell-quoted value of each line's id key into parallel's command text for that
line.
A common use case I've found this syntax helpful for is piping results of
"list" JSON API endpoints into their respective "describe" endpoints.
Example: Use the gh CLI <https://cli.github.com> to list Github Actions
workflow runs, fetch the list of jobs in each, and grep the logs of a specific
job:
> $ gh run list --branch=main --workflow="CI" --created="$(date -d '90 days
> ago' -I)..*" --json=databaseId --jq=.[] \
> | parallel gh run view {[.databaseId]} --json=jobs --jq='.jobs[] |
> select(.name == "The Job I Want")' \
> | parallel gh run view --log --job={[.databaseId]} \
> | grep 'some specific log line'
Here's the implementation (also linked here
<https://gist.github.com/vergenzt/864010adbac64def312190d85607109b>), which I
add to my ~/.parallel/config so it's always available:
> --rpl '{[(.*?)]} uq(); $Global::use{"IPC::Open2"} ||= eval "use IPC::Open2;
> 1;"; my $jq = open2(my $jq_out, my $jq_in, "jq", "-Rrc", "[ try(fromjson) //
> . | $$1 | tostring ] | join(\" \")") or die "Could not open pipe to jq!";
> print $jq_in $_; close $jq_in; $_ = <$jq_out>; chomp $_; waitpid $jq, 0; $?
> && die'
It's a bit of a mouthful. 🫠(And IIRC I think I had to put it all on one line
because parallel expects each config file argument on one line only.)
If properly cleaned up, would there be any interest & openness from the
maintainers in adding jq-expression placeholder syntax (either {[...]} or in
some other form) into parallel directly? Maybe under the --plus flag?
I'd love to hear your thoughts!
Tim
