I'm using jq to parse a JSON file as shown here. However, the results for string values contain the "double-quotes" as expected:
$ cat json.txt | jq '.name' "Google" How can I pipe this into another command to remove the ""?
$ cat json.txt | jq '.name' | other_command Google Use the -r (or --raw-output) option to emit raw strings as output:
jq -r '.name' <json.txt 
tr -d '"'.
"Mack \"The Knife\" Smith", you want it to change to Mack "The Knife" Smith, not Mack The Knife Smith." can never exist as literal data as opposed to syntax, it's irresponsible to assume such to be the case. (I work in security, and see sooo many issues misclassified as "input validation" failures when they're really failure to design for the full input domain)
jq -r '.name' json.txt works just fine<json.txt reads from the file json.txt, whereas >json.txt empties the file json.txt and then writes to it. The OP here is using cat json.txt, so they want to read from the file, so < is correct.So for a file containing just {"name": "Google"} then yes
sample='{"name":"Google"}' echo $sample| jq '.name' "Google" using --raw-output helps
echo $sample| jq --raw-output '.name' Google But I stumbled upon this question because I was using --raw-output on a json array like this
sample='[{"name":"Yahoo"},{"name":"Google"}]' echo $sample | jq --raw-output 'map(.name)' [ "Yahoo", "Google" ] And I didn't understand why the quotes remained. I came across this post, and now I know adding | .[] does the trick!
echo $sample | jq --raw-output 'map(.name)| .[]' Yahoo Google 
echo $sample is itself buggy. See I just assigned a variable, but echo $variable shows something else! -- always echo "$sample", with the quotes; or, even better, printf '%s\n' "$sample"For me, it's more logical to detect an array first and then select a needed key:
sample='[{"name":"Yahoo"},{"name":"Google"}]' echo $sample | jq -r '.[] | .name' Yahoo Google 
cat foo | baris significantly less efficient thanbar <fooor its equivalent<foo bar, especially ifbaris a program likesortthat can parallelize its operations when given a seekable file descriptor as opposed to a FIFO (which can only be read once front-to-back). It both means more startup overhead (invoking/bin/cat), and more context switches between userspace and kernel (each piece of content going through aread()withincat, then awrite()to a FIFO incat, and then aread()inside your destination program, instead of skipping to that last step directly).cat foo | wc -c, vswc -c <foo-- in the latter case it can just do two syscalls,seek()andtell(), to get the exact size of the file now matter how long it is; in the former, it needs to read to the end, even if that's gigabytes of content, because onlycathas direct access to the original file, andwchas no way to request metadata on it.