5 ms·

I don't find this grep-able at all: json[0].commit.author.name = "Tom Hudson"; Now I need to escape brackets and dots in regex. Genius! I have 5 line (!)

I don't find this grep-able at all: json[0].commit.author.name = "Tom Hudson"; Now I need to escape brackets and dots in regex. Genius! I have 5 line (!) jq script that produces this: json_0_commit_author_name='Tom Hudson' This is what I call grep-able. It's also eval-able. > What if there's json object with commit and json_commit? Then I'll use jq to filter it appropriately or change delimiter. The point is ease of use for grep and shell.

necrotic_comp 6y ago
Can you share the jq script ?
armagon 6y ago
What is your jq script?
- inshadows 6y ago
  #!/usr/bin/jq -rf tostream | select(length == 2) | ( ( [ .[0][] | tostring | gsub("[^\\w]"; "_") ] | join("_") ) + "=" + ( .[1] | tostring | @sh ) )
hiperlink 6y ago
With `fgrep` and quoteing in 's You don't have to escape anything.
TomNomNom 6y ago
I think this is a good point. It's definitely hard to grep for certain parts of gron's output; especially where there's arrays involved because of the square brackets. I find that using fgrep/grep -F can help with that in situations where you don't need regular expressions though. It's not an ideal output format for sure, but it does meet some criteria that I considered to be desirable. Firstly: it's unambiguous. While your suggested format is easier to grep, it is also lossy as you mention. One of my goals with gron was to make the process reversible (i.e. with gron -u), which would not be possible with such a lossy format. Secondly: it's valid JavaScript. Perhaps that's a minor thing, but it means that the statements are eval-able in either Node.js or in a browser. It's a fairly small thing, but it is something I've used on a few occasions. Using JavaScript syntax also means I didn't need to invent new rules for how things should be done, I could just follow a subset of existing rules. FWIW, personally I'm usually using gron to help gain a better understanding of the structure of an object; often trying to find where a piece of known data exists, which means grepping for the value rather than the key/path - avoiding many of the problems you mention. Thanks for your input :) I'd like to see your jq script to help me learn some more about jq!

necrotic_comp 6y ago

Can you share the jq script ?

armagon 6y ago

What is your jq script?

inshadows 6y ago
#!/usr/bin/jq -rf tostream | select(length == 2) | ( ( [ .[0][] | tostring | gsub("[^\\w]"; "_") ] | join("_") ) + "=" + ( .[1] | tostring | @sh ) )

hiperlink 6y ago

With `fgrep` and quoteing in 's You don't have to escape anything.

TomNomNom 6y ago

I think this is a good point. It's definitely hard to grep for certain parts of gron's output; especially where there's arrays involved because of the square brackets. I find that using fgrep/grep -F can help with that in situations where you don't need regular expressions though. It's not an ideal output format for sure, but it does meet some criteria that I considered to be desirable. Firstly: it's unambiguous. While your suggested format is easier to grep, it is also lossy as you mention. One of my goals with gron was to make the process reversible (i.e. with gron -u), which would not be possible with such a lossy format. Secondly: it's valid JavaScript. Perhaps that's a minor thing, but it means that the statements are eval-able in either Node.js or in a browser. It's a fairly small thing, but it is something I've used on a few occasions. Using JavaScript syntax also means I didn't need to invent new rules for how things should be done, I could just follow a subset of existing rules. FWIW, personally I'm usually using gron to help gain a better understanding of the structure of an object; often trying to find where a piece of known data exists, which means grepping for the value rather than the key/path - avoiding many of the problems you mention. Thanks for your input :) I'd like to see your jq script to help me learn some more about jq!