4 ms·
Then you wouldn't be able to reliably use shell substitution to pass in values, which is a pity. The issue being if $var contained commas, like var="foo,y=b
by jffry 5y ago
Then you wouldn't be able to reliably use shell substitution to pass in values, which is a pity. The issue being if $var contained commas, like
var="foo,y=bar"
curl --jp "x=$var"
Then allowing comma-separated field=value pairs within a single --jp argument would cause non-obvious changing behavior
- hnarn 5y agoYou could possibly solve it by supporting single quotes for value containment: curl --jp "x='$var'" Gives: curl --jp "x='foo,y=bar'" Assuming that is what you meant. Isn’t this normally how these things are handled in unix shells? That and escaping which probably doesn’t apply here. I don’t know what the best way to implement this would be, but the current proposal looks so weird for me that I’m either completely missing something or it’s wildly unnecessary.
- jffry 5y agoIf you do something like single quotes then you can no longer use the shell's abilities to properly pass in escaped values like this: bash$ foo=this\"test\" bash$ echo "value of \$foo is: $foo" value of $foo is: this"test" If we're throwing away the ability to let the shell handle escaping properly then there's really no point to --jq at all versus just manually attempting to cobble together JSON directly