[HN Gopher] Jaq - A jq clone focused on correctness, speed, and ...
___________________________________________________________________
Jaq - A jq clone focused on correctness, speed, and simplicity
Author : tmcneal
Score : 259 points
Date : 2023-11-29 16:13 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mgaunard wrote:
| While jq is a very powerful tool, I've also been using DuckDB a
| lot lately.
|
| SQL is a much more natural language if the data is somewhat
| tabular.
| suchar wrote:
| Some time ago I tried Retool and it does have "Query JSON with
| SQL": https://docs.retool.com/queries/guides/sql/query-json (it
| is somewhat relevant because it was extremely convenient)
|
| It is somewhat similar to Linq in C# although SQL there is more
| standardised so I like it more. Also, it would be fantastic to
| have in-language support for querying raw collections with SQL.
| Even better: to be able to transparently store collections in
| Sqlite.
|
| It is always sad to see code which takes some data from
| db/whatever and then does simple processing using loops/stream
| api. SQL is much higher level and more concise language for
| these use cases than Java/Kotlin/Python/JavaScript
| MrDrMcCoy wrote:
| I like textql [0] better for this use case, as it's simpler in
| my mind.
|
| [0] https://github.com/dinedal/textql
| bdcravens wrote:
| textql doesn't seem to work with JSON. I think the
| grandparent comment meant that the data was in a table of
| sorts, represented in JSON.
| MrDrMcCoy wrote:
| Ah, you're right. TextQL combined with Miller would be
| closer, but DuckDB can do the same things all in one.
| Always good to have a variety of tools to choose from.
| CBLT wrote:
| I've found the same. I store all raw json output into a sqlite
| table, create virtual columns from it, then do a shell loop off
| of a select. Nested loops become unnested, and debugability is
| leagues better because I have the exact record in the db to
| examine and replay.
|
| I've noticed what I'm creating are DAGs, and that I'm
| constantly restarting it from the last-successfully-proccessed
| record. Is there a `Make`-like tool to represent this? Make
| doesn't have sql targets, but full-featured dag processors like
| Airflow are way too heavyweight to glue together shell
| snippets.
| loudmax wrote:
| I applaud this project's focus on correctness and efficiency, but
| I'd also really like a version of `jq` that's easy to understand
| without having to learn a whole new syntax.
|
| `jq` is a really powerful tool and `jaq` promises to be even more
| powerful. But, as a system administrator, most lot of the time
| that I'm dealing with json files, something that behaved more
| like grep would be sufficient.
| msluyter wrote:
| Obligatory reference to "gron" ("make JSON greppable"), which I
| find to be quite useful for many common tasks:
|
| https://github.com/tomnomnom/gron
| ishandotpage wrote:
| Have you tried `gron`?
|
| It converts your nested json into a line by line format which
| plays better with tools like `grep`
|
| From the project's README:
|
| > gron "https://api.github.com/repos/tomnomnom/gron/commits?per
| _page..." | fgrep "commit.author"
|
| json[0].commit.author = {};
|
| json[0].commit.author.date = "2016-07-02T10:51:21Z";
|
| json[0].commit.author.email = "mail@tomnomnom.com";
|
| json[0].commit.author.name = "Tom Hudson";
|
| https://github.com/tomnomnom/gron
|
| It was suggested to me in HN comments on an article I wrote
| about `jq`, and I have found myself using it a lot in my day to
| day workflow
| hu3 wrote:
| Thank you so much. This seems like a saner approach for some
| simpler use cases.
|
| It flattens the structure. And makes for easy diffing.
| evntdrvn wrote:
| There's also this awesome tool to make JSON interactively
| navigable in the terminal:
|
| https://fx.wtf
| llimllib wrote:
| https://jless.io/ is similar, and will give you jq
| selectors so the two combine very well. (fx might have
| that feature too, I dunno)
| sn0wf1re wrote:
| You can also mimic gron, including support for yaml with
|
| yq -o=props my-file.yaml
| stronglikedan wrote:
| This is awesome, thanks! Not OP, but this will help me to
| write specifications for modifying existing JSON structures
| immensely. It's kind of a pain parsing JSON by (old man) eye
| to figure out which properties are arrays, and follow
| property names down a chain. This will definitely help
| eliminate mistakes!
| pdimitar wrote:
| Also try jless[0], it's amazingly convenient and it shows
| you a JSON path at the bottom of the screen as you
| navigate.
|
| [0] https://jless.io/
| jbverschoor wrote:
| This looks some much better as an ad-hoc tool. Would be cool
| if it supported more formats - plist, yaml, xml (hoow to do
| body, or conflicting attr/elements)
| jrockway wrote:
| One of my coworkers really likes Miller:
| https://github.com/johnkerl/miller
|
| The idea is that you get awk/grep like commands for operating
| on structured data.
| INTPenis wrote:
| jq, and yq, are tools you spend an hour figuring out and then
| leave them in a CI pipeline for 3 years.
| zellyn wrote:
| ChatGPT excels at producing `jq` incantations; I can actually
| use `jq` now...
| frou_dh wrote:
| > I'd also really like a version of `jq` that's easy to
| understand without having to learn a whole new syntax.
|
| Since JSON is JavaScript Object Notation, then an obvious non-
| special-snowflake language for such expressions on the CLI is
| JavaScript: https://fx.wtf/getting-started#json-processing
| gchamonlive wrote:
| It is a little early to say, but I have been learning how
| nushell deals with structured data and it seems like it is very
| usable for simple cases to produce readable one-liners, and if
| you need to bring out the big guns the shell is also a full
| fledged scripting language. Don't know about how efficient it
| is though.
|
| It needs to justify moving to a completely different shell, but
| the way you deal with data in general does not restrict itself
| to manipulating json, but also the output of many commands, so
| you kinda have one unified piping interface for all these
| structured data manipulations, which I think is neat.
| bobbylarrybobby wrote:
| From the data side, nushell uses polars for querying tabular
| data so it should be pretty fast. Not sure about its
| scripting language.
| hyperthesis wrote:
| Maybe like SQL for relational algebra? Codd made two query
| languages that were "too difficult for mortals to use".
| (B-trees for performance was a separate issue)
|
| But jq's strength is its syntax - the difficulty is the
| semantics.
| notatoad wrote:
| there's got to be _some_ syntax though. jq does a unique
| function that isn 't defined in any other syntax. i'm with you,
| the jq syntax is weird and sometimes difficult to understand.
| but the replacement would just be some different syntax.
|
| these little one-off unique syntaxes that i'm never going to
| properly learn are one of my favourite uses of chatGPT.
| visarga wrote:
| This language must be the spiritual successor of Perl
| TurboHaskal wrote:
| I inherited some piece of code that made use of an extremely
| long and complicated jq script.
|
| I simply gave up understanding the whole thing, and restored
| the balance in the universe by rewriting it in Perl.
| hnlmorg wrote:
| Now you just need to rewrite Perl in Rust and compile that to
| WebAssembly. And the circle of HN is complete.
| LargeTomato wrote:
| I know perl is useful. I know it's going to help me. It seems
| like you can get away with a quick perl script whereas a
| python script would attract scrutiny.
|
| But it's such a painful language to look at.
| pizza_pleb wrote:
| Somewhat off-topic, but is there a tool which integrates
| something like this/jq/fx and API requests? I'd like to be able
| to do some ETL-like operations and join JSON responses
| declaratively, without having to write a script.
| awayto wrote:
| Is there anything out there like "SELECT * FROM "http://..."?
| hnlmorg wrote:
| My shell will do that open http://... |
| select * where ... # FROM can be omitted because
| you're loading a pipe
|
| https://murex.rocks/optional/select.html
| pizza_pleb wrote:
| I think a query language would be great, with a way to
| subquery/chain data from previous requests (e.g. by jsonpath)
| to subsequent ones.
|
| The closest I've gotten is to wrap the APIs with GraphQL.
| This achieves joining, but requires strict typing and coding
| the schema+relationships ahead of time which restricts query
| flexibility for unforeseen edge cases.
|
| Another is a workflow automation tool like n8n which isn't as
| strict and is more user-friendly, but still isn't very
| dynamic either.
|
| Postman supports chaining, but in a static way with
| getting/setting env variables in pre/post request JS scripts.
|
| Bash piping is another option, and seems like a more natural
| fit, but isn't super reusable for data sources (e.g. with
| complex client/auth setup) and I'm not sure how well it would
| support batch requests.
|
| It would be an interesting tool/language to build, but I
| figure there has to be a solution out there already.
| RyanHamilton wrote:
| I'm working on a project I call babeldb. It allows "select *
| from query_rest('https://api1.binance.com/api/v3/exchangeInfo
| #.symbols')" The #.symbols at the end is actually jq path
| expression, it's sometimes needed when the default json to
| table is suboptimal. You can see it in action by selecting
| babeldb in the dropdown, then clicking "Run All" here: https:
| //pulseui.net/sqleditor?qry=select%20*%20from%20query_...
| fyzix wrote:
| I think my benchmark[1] would be a great test for this. The jq[2]
| version takes 50s on my machine.
|
| [1] : https://github.com/jinyus/related_post_gen
|
| [2]:
| https://github.com/jinyus/related_post_gen/blob/main/jq/rela...
| rad_gruchalski wrote:
| I started using yq over jq. Any significant differences?
| MrDrMcCoy wrote:
| Which yq? I prefer https://github.com/mikefarah/yq to
| https://github.com/kislyuk/yq.
| Yasuraka wrote:
| I prefer the former, single static binary which works great
| on workstations and CI alike, the latter requires python as
| well as jq as it's a wrapper
| bbkane wrote:
| I've been using yq + git-xargs to automate config files in
| repos (CI/CD, linters, etc). The combo has been spectacular
| for me.
|
| https://github.com/bbkane/git-xargs-tasks
| rad_gruchalski wrote:
| The former: https://gruchalski.com/posts/2023-07-10-yq-the-
| yaml-power-to....
| a-nikolaev wrote:
| jq feels like a much more robust tool than yq. I understand
| that the task of processing YAML is much harder than JSON, but:
|
| - yq changed its syntax between version 3 and 4 to be more like
| jq (but not quite the same for some reason)
|
| - yq has no if-then-else
| https://github.com/mikefarah/yq/issues/95 which is a poor
| design (or omission) in my opinion
|
| So yq works when you need to process YAML, it can even handle
| comments quite well. Buy for pure JSON processing jq is a
| better tool.
| dilsmatchanov wrote:
| Haven't checked yet, but I am sure it's written in Rust
| jeffbee wrote:
| I guess it's cute that there's some terminal line art library in
| Rust somewhere, but when I tried to invoke jaq it just pooped
| megabytes of escape codes into my iTerm and eventually iTerm
| tried to print to the printer. Too clever.
|
| I tried to do `echo *json | rush -- jaq -rf ./this-program.jq {}
| | datamash ...` and in that context I don't think it's
| appropriate to try to get artistic with the tty.
|
| The cause of the errors, for whatever it's worth, is that `jaq`
| lacks `strftime`.
| gigatexal wrote:
| It's so awesome when projects shout out other projects that
| they're similar to or inspired by or not replacements for. I
| learned about https://github.com/yamafaktory/jql from the readme
| of this project and it's what I've been looking for for a long
| time, thank you!
|
| That's not to take away from JAQ by any means I just find the JQ
| style syntax uber hard to grokk so jql makes more sense for me.
| jjeaff wrote:
| Nice find. I think I'll try it out. Although I was hoping for a
| real SQL type experience. I don't understand why no one just
| copies SQL so I can write a query like "SELECT * FROM $json
| WHERE x>1".
|
| Everyone seems to want to invent their own new esoteric
| symbolic query language as if everything they do is a game of
| code golf. I really wish everyone would move away from this old
| Unix mentality of extremely concise, yet not-self-evident
| syntax and do more like the power shell way.
| soulbadguy wrote:
| While i agree about the general sentiment on preferring well
| defined and explicit standard as opposed to "cute" custom
| made languages. In this case i am not convince that SQL would
| be the best candidate for querying nested structures like
| JSON.Something like xpath maybe.
| jjeaff wrote:
| I agree, it wouldn't be the best to handle all json edge
| cases, but it would be a super easy way to quickly get data
| from a big chunk of simple json and you could just use
| subqueries or query chaining for nested results.
|
| For anyone who hasn't used powershell, this is the
| difference I'm talking about. I would not be able to write
| either of these without looking up the syntax. But knowing
| very little about powershell, I can tell exactly what that
| command means while the bash command, not so much.
|
| ```powershell $json | ConvertFrom-Json | Select-Object
| -ExpandProperty x ```
|
| ```bash echo $json | jq '.x' ```
| justinsaccount wrote:
| The datafusion cli https://arrow.apache.org/datafusion/user-
| guide/cli.html can run SQL queries against existing json
| files.
| filmor wrote:
| SQL is built for relational/tabular data, JSON is not
| relational and usually not tabular.
| im3w1l wrote:
| Well there is nothing saying you can't put relational data
| in json format.
| stevage wrote:
| But that wouldn't help query arbitrary JSON files which
| was the point.
| pdntspa wrote:
| Be the change you want to see.
|
| I personally don't understand why people aren't willing to
| learn instead. It's not hard to sit down and pick up a new
| skill and it's good to step out of one's comfort zone. I
| personally hate Powershell syntax, brevity is the soul of wit
| and PS could learn a thing or two from bash and "the linux
| way".
|
| We seem obsessed with molding the machine to our individual
| preferences. Perhaps we should obsess over the opposite:
| molding our mind to think more like the machine. This keeps a
| lot of things simple, uncomplicated, and flexible.
|
| Does a painter wish for paints that were more like how he
| wanted them to be? Sure, but at the end of the day he buys
| the same paint everyone else does and learns to work with his
| medium.
| unsui wrote:
| While I appreciate the sentiment for bending your mind,
| rather than the spoon, the practical reality is that
| developer time is far costlier than compute time.
|
| It is easier to map compute structures and syntax to
| existing mental models than to formulate new mental models.
| The latter is effortful and time-consuming.
|
| So, given the tradeoffs, I could learn a new language, or
| leverage an existing language to get things done.
|
| And yes, given sufficient resources (particularly time),
| developing new mental models is ideal, but reality often
| prohibits the ideal.
| 3np wrote:
| If the crux is that you want something that maps closer
| to your personal mental model than what's available, I
| guess the other option is to build the missing tool
| yourself. That's the other side of "be the change you
| want to see".
|
| > So, given the tradeoffs, I could learn a new language,
| or leverage an existing language to get things done.
|
| There is also the option to create a new language (jqsql
| or whatnot), optionally sharing it publically.
| stevage wrote:
| In my case, my memory doesn't work that way. I have learnt
| jq several times but I don't use it frequently enough to
| retain the knowledge.
|
| A better tool for me would be something that uses JS syntax
| but with some syntactic sugar and a great man page.
| Grimburger wrote:
| >I personally don't understand why people aren't willing to
| learn instead.
|
| Mostly because if you don't use it that often then it ends
| up forgotten again. I can smash out plenty of trivial
| regexes, but anything even slightly complicated means I'm
| learning backreferences again for the 6th time in a decade.
| pdimitar wrote:
| > _I personally don 't understand why people aren't willing
| to learn instead_
|
| You misunderstand. As programmers we learn every day,
| obviously that's one of our strong points.
|
| The real problem is that every single tool wants you to go
| deep and learn their particular dyslexic mini programming
| language syntax or advanced configuration options syntax.
| Why? We have TOML, we have SQL, we have a bunch of pretty
| proven syntaxes and languages that do the job very well.
|
| A lot of these programmers authoring tools suffer from a
| severe protagonist syndrome which OK, it's their own
| personal character development to grapple with, but in the
| meantime us the working programmers are burning out because
| everyone and their dog wants us to learn their own brain
| child.
| imiric wrote:
| > We seem obsessed with molding the machine to our
| individual preferences. Perhaps we should obsess over the
| opposite: molding our mind to think more like the machine.
|
| How so? Everything in "the machine" was created by other
| humans; from the latest CLI tool, to the CPU instruction
| set. As computer users, given that it's practically
| impossible for a single person to be familiar with all
| technologies, we must pick our battles and decide which
| technology to learn. Some of it is outdated, frustrating to
| use, poorly documented or maintained, and is just a waste
| of time and effort to learn.
|
| Furthermore, as IT workers, it is part of our job to choose
| technologies worth our and our companies' time, and our
| literal livelihood depends on honing this skill.
|
| So, yes, learning new tools is great, but there's only so
| much time in a day, and I'd rather spend it on things that
| matter. Even better, if no tool does what I want it to, I
| have the power to create a new one that does, and increase
| my development skills in the process.
| vips7L wrote:
| brevity is not clarity.
| screature2 wrote:
| I think the closest I've seen to a SQL experience for JSON is
| how steampipe stores json columns as jsonb datatypes and
| allows you to query those columns w/postgres JSON functions
| etc.
|
| - https://steampipe.io/docs/sql/querying-json#querying-json
| #example w/the AWS steampipe plugin (I think this is a
| wrapper around the AWS go SDK)
|
| - https://hub.steampipe.io/plugins/turbot/config #I think
| this lets you query random json files.
|
| (edited to try to fix the bulleting)
| bobobar339 wrote:
| DuckDB does just this, https://duckdb.org/docs/archive/0.9.2/
| guides/import/json_imp...
| pgeorgi wrote:
| > Although I was hoping for a real SQL type experience. I
| don't understand why no one just copies SQL so I can write a
| query like "SELECT * FROM $json WHERE x>1".
|
| With somewhat tabular data, you can use sqlite to read the
| data into tables and then work from there.
|
| Example 10 from https://opensource.adobe.com/Spry/samples/dat
| a_region/JSONDa... (slightly fixed by removing the ellipsis)
| results in this interaction: sqlite> select
| json_extract(value, '$.id'), json_extract(value, '$.type')
| from json_each(readfile('test.json'),
| '$.items.item[0].batters.batter'); 1001|Regular
| 1002|Chocolate 1003|Blueberry 1004|Devil's
| Food sqlite> select json_extract(value, '$.id'),
| json_extract(value, '$.type') from
| json_each(readfile('test.json'), '$.items.item[0].topping');
| 5001|None 5002|Glazed 5005|Sugar
| 5007|Powdered Sugar 5006|Chocolate with Sprinkles
| 5003|Chocolate 5004|Maple
|
| Instead of "select" this could also flow into freshly created
| tables using "insert into" for more complex scenarios.
| PhilippGille wrote:
| I can also recommend checking https://github.com/tidwall/jj
| stevage wrote:
| That looks excellent, thank you!
| Valodim wrote:
| Very nice in this regard is gron, too. It simply flattens any
| json into lines of key value format, making it compatible with
| grep and other simple stream operations.
|
| https://github.com/tomnomnom/gron
| mstade wrote:
| This is brilliant, thank you for sharing!
| OJFord wrote:
| I do sympathise with that a bit, but for me at least it does
| not look like jql is the solution:
| '|={"b""d"=2, "c"}'
|
| this appears to be something like jq's:
| 'select(."b"."d" == 2 or ."c" != null)'
|
| which.. is obviously longer, but I think I prefer it, it's
| clearer?
|
| (actually it would be `.[] | select(...)`, but I'm not sure
| something like that isn't true of jql too without trying it, I
| don't know if the example's intended to be complete - and I
| don't think it affects my verdict)
| lopatin wrote:
| Regarding correctness, will it display uint64 numbers without
| truncating them? That's my biggest pet peeve with jq currently.
| necubi wrote:
| Unfortunately JSON numbers are 64 bit floats, so if you're
| standards compliant you have to treat them as such, which gives
| you 53 bits of precision for integers.
|
| Also hey, been a while ;)
|
| Edit: I stand corrected, the latest spec (rfc8259) only
| formally specifies the textual format, but not the semantics of
| numbers.
|
| However, it does have this to say:
|
| > This specification allows implementations to set limits on
| the range/and precision of numbers accepted. Since software
| that implements IEEE 754 binary64 (double precision) numbers
| [IEEE754] is generally available and widely used, good
| interoperability can be achieved by implementations that expect
| no more precision or range than these provide, in the sense
| that implementations will approximate JSON numbers within the
| expected precision.
|
| In practice, most implementations treat JSON as a subset of
| Javascript, which implies that numbers are 64-bit floats.
| Groxx wrote:
| JSON does not define a precision for numbers, so: it's
| _often_ float64 (but note -0 is allowed, but NaN and + /-Inf
| are not), but it depends on your language, parser config,
| etc.
|
| Many will produce higher precision but parse as float64 by
| default. But maximally-compatible JSON systems should always
| handle arbitrary precision.
| matt_kantor wrote:
| I'm being pedantic here, but JSON numbers are sequences of
| digits and ./+/-/e/E. Whether to parse those sequences into
| 64-bit floats or something else is left up to the
| implementation.
|
| However what you say is good practice anyway. The spec (RFC
| 8259) has this note on interoperability:
|
| > This specification allows implementations to set limits on
| the range and precision of numbers accepted. Since software
| that implements IEEE 754 binary64 (double precision) numbers
| [IEEE754] is generally available and widely used, good
| interoperability can be achieved by implementations that
| expect no more precision or range than these provide, in the
| sense that implementations will approximate JSON numbers
| within the expected precision. A JSON number such as 1E400 or
| 3.141592653589793238462643383279 may indicate potential
| interoperability problems, since it suggests that the
| software that created it expects receiving software to have
| greater capabilities for numeric magnitude and precision than
| is widely available.
| rdtsc wrote:
| > Unfortunately JSON numbers are 64 bit floats, so if you're
| standards compliant you have to treat them as such,
|
| Are you sure? Looking at https://www.json.org/json-en.html I
| don't see anything about 64 bit floats.
| lopatin wrote:
| I thought the JSON spec says that numbers can have an
| arbitrary amount of digits.
|
| Also, what!! Hey! Miss you man.
| re wrote:
| I believe this has improved in jq 1.7:
| https://github.com/jqlang/jq/releases/tag/jq-1.7
|
| > Use decimal number literals to preserve precision. Comparison
| operations respects precision but arithmetic operations might
| truncate.
| wwader wrote:
| jq 1.7 do preserve large integers but will truncate if any
| operation is done on them. Unfortunetly it currently truncates
| to a decimal64 which is a bit confusing, this will be fixed in
| next release where it follow the suggestion from the JSON spec
| and truncates to binary64 (double)
| https://github.com/jqlang/jq/pull/2949
| stickfigure wrote:
| Congratulations! We're almost back to the basic functionality we
| used to have with XSLT.
| nurettin wrote:
| To be fair, xslt is a lot more verbose than `map(.*2)`
| sigmonsays wrote:
| why not contribute to the existing jq project instead of starting
| a new one?
|
| We have so many json query tools now it's insane.
| sillysaurusx wrote:
| Fun, of course. Existing projects are boring almost by
| definition. And this is volunteer work.
| lilyball wrote:
| The obvious reason here is jaq makes some changes to semantics,
| changes which would be rejected by jq.
|
| Another likely reason is that it seems a motivation for jaq is
| improving the performance of jq. Any low-hanging fruit there in
| the jq implementation was likely handled a long time ago, so
| improving this in jq is likely to be hard. Writing a brand new
| implementation allows for trying out different ways of
| implementing the same functionality, and using a different
| language known for its performance helps too.
|
| Using a language like Rust also helps with the goal of ensuring
| correctness and safety.
| anonymoushn wrote:
| One reason to do this is that often performance improvements
| involve architectural overhauls that maintainers are unlikely
| to approve of.
| Yanael wrote:
| jq have been in my toolbox since a while it's a very great tool.
| But yet another query language to learn, jaq seems identical on
| that. I think that's where LLMs can help a lot to make it easier
| for adoption, I started a project on that note to manipulate the
| data just with natural language, https://partial.sh
|
| 'cat' your json file and describe what you want I think should be
| the way to go
| LargeTomato wrote:
| I usually avoid those types of tools. It looks way too fragile
| and the examples look a bit magical. Do you think it's stable
| and easy to use?
| jhatemyjob wrote:
| I switched to jless and never looked back. The user interface is
| miles ahead of everything else
| vjust wrote:
| I find jq's syntax (and docs) kind of opaque, but I guess we have
| no other options. And I don't think this latest incarnation
| breaks any new ground there. But it'd be better if I just wrote
| it myself - "be the change ...."
| stevage wrote:
| Well, as pointed out in the jaq docs there is jql.
|
| But I just looked at jql and I liked it even less. The pedantry
| about requiring all keys in selectors to be double quoted is,
| um, painful for a CLI tool.
| stevage wrote:
| Someone else above pointed out JJ which looks much easier to
| use.
| wrsh07 wrote:
| ChatGPT or the warp chatbot is pretty good at jq syntax
| WhereIsTheTruth wrote:
| https://github.com/01mf02/jaq/blob/main/Cargo.lock
|
| That's a lot of dependencies..
| j1elo wrote:
| > _[[]] | implode crashes jq, and this was not fixed at the time
| of writing despite being known since five years._
|
| Well, taking into account that jq development has been halted for
| 5 years and only recently revived again, it's no wonder that bug
| reports have been sitting there for that time, both well known
| and new ones. I bet they'll get up to speed and slowly but surely
| clear the backlog that has built up all this time.
| wwader wrote:
| Yeap was fixed in 1.7 https://github.com/jqlang/jq/pull/2646
| icco wrote:
| I use `yq` for this stuff and it handles most of this pretty
| well.
| Yanael wrote:
| How have you been using jq? It is more adhoc for exploring JSON
| files during development/data analysis or in programs that run in
| production?
| wwader wrote:
| Quite a lot! i use it to explode both JSON and tex (parse using
| jq functions). I also use it for exploring ane debug binary
| formats (https://github.com/wader/fq). Now a days i also use it
| for some adhoc programming and a calculator.
| Yanael wrote:
| Oh sounds a very neat way to explore binary!
| 1vuio0pswjnm7 wrote:
| All else being equal, does the speed of jaq change with the size
| of the input.
___________________________________________________________________
(page generated 2023-11-29 23:00 UTC)