1) refuses to operate on stdin; requires a filename argument, which is so irritating. 2) doesn't accept values that jq accepts % time jq -r '[expression]'
1 is easy to work around (handy tip incoming for any tools that _seem_ to not support stdin but actually do, as stdin is also available as a file in unix): echo '{"foo": "bar"}' | query-json ".foo" /dev/stdin
Q: A faster re-implementaiton of jq written in Reason Native/OCaml
141–150 of 196 posts
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#1421) refuses to operate on stdin; requires a filename argument, which is so irritating. 2) doesn't accept values that jq accepts % time jq -r '[expression]'
1 is easy to work around (handy tip incoming for any tools that _seem_ to not support stdin but actually do, as stdin is also available as a file in unix): echo '{"foo": "bar"}' | query-json ".foo" /dev/stdin
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#143Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#144Earlier quoted context omitted.
My most common jq usage is to copy and paste some json into quotes to make it easier to read. My second most common action is to chain curl and jq together. A replacement for jq that doesn’t use stdin is literally useless to me.
I think at least two people in the thread pointed out that you can use /dev/stdin as a file.
Yes, q is supposedly faster than jq. But it is exceedingly rare for me to ever have any performance problems with jq, especially since it’s essentially a one off utility I use occasionally, not as part of the hot loop of any workflow where performance matters.
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#145I used to be a regular user of jq, but I was never parsing very large JSON. I now do what I used to do with jq in my browser's developer tools console. Map and filter are far more familiar than jq's syntax where I found myself referring to the documentation most of the time. I'm sure other people have use cases where the browser wouldn't meet their needs, but for me, I find jq unnecessary.
Writing a script? I'm not going to have my script open a web browser so I can attempt to interact with a web console.
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#146Hm, I thought q is synonym for querying CSV files https://harelba.github.io/q/
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#147Slightly out of context here, I find the entire stack of bsb, bsb-native, ocaml and esy pretty cool. However, I just dont find enough resources, good tutorials etc on Google search. Is there a good set of beginner tutorials anyone can point to ? Thanks in advance.
The documentation is a problem in the OCaml world and a problem with Reason Native as well. I found myself pretty lost some times, esy.sh should be a initial point in contact for most of Reason related stuff. Menhir/sedlex and others are pretty high accessibility barrier for new commers. One of the nice things about all of it it's the discord, it's friendly and always helpful. Hope it helps, just let me know if there…
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#1481) refuses to operate on stdin; requires a filename argument, which is so irritating. 2) doesn't accept values that jq accepts % time jq -r '[expression]'
1 is easy to work around (handy tip incoming for any tools that _seem_ to not support stdin but actually do, as stdin is also available as a file in unix): echo '{"foo": "bar"}' | query-json ".foo" /dev/stdin
Two examples I can remember off the top of my head:
- Nix build scripts
- OpenMoko
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#149Earlier quoted context omitted.
Yes, I don't understand how people end up with assertions that the filename is a require argument. At least we've got /dev/stdin or /proc/self/fd/0 as workarounds.
Much Unix software today is written by people who really don't appreciate or understand Unix. It leads to things like Homebrew (early on, at least) completely taking over and breaking /usr/local; to command-line utilities using a single dash (-) precending both short and long option names (granted, --long-opts is a GNUism, but it's a well-established standard); commands that output color by default even when the outp…
Fully agree with you, but oh well, most if not everything is available on Macports anyway.
> There are an enormous number of tools out there that only exist because people don't know how to chain together basic 1970s Unix text-processing tools in a pipeline.
Speed. A specialized tool you need often beats manually wrangling the dozen or so Unix tools you need to replace it, plus many Good Options are only available on the GNU/Linux coreutils and don't work on Macs (sed -i, my most common annoyance) or busybox.
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#150For everyone pining for a Jq with a different syntax: I have a bunch of links to alternatives collected, you might want to try some of them (some may be for different things than JSON): https://github.com/fiatjaf/awesome-jq https://github.com/TomConlin/json2xpath https://github.com/antonmedv/fx https://github.com/fiatjaf/jiq https://github.com/simeji/jid https://github.com/jmespath/jp https://github.com/cube2222/jql…