Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Q: A faster re-implementaiton of jq written in Reason Native/OCaml

github.com

Post reply on HN
Print view View original

151–160 of 196 posts

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#151

Post by mcguire »

jeffbee wrote: post #81
caymanjim wrote: post #77

Earlier quoted context omitted.

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…

The `go` program uses -longopts and I think it would be hard to argue that Rob Pike lacks an appreciation of Unix traditions.

Rob Pike lacks an appreciation of GNU traditions.

I'm actually surprised by this; I would have expected Pike to go with single-letter options only.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#152

Post by retzkek »

aasasd wrote: post #82

For 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…

Babashka is another Hy-like alternative, but based on Clojure, and recently discussed on HN:

https://github.com/borkdude/babashka

https://news.ycombinator.com/item?id=24353476

Aside: another nice tool I recently discovered for working with JSON and YML, doing conversion and diffs (especially helpful for generated files):

https://github.com/homeport/dyff

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#153

Post by derefr »

vlovich123 wrote: post #134
derefr wrote: post #101

Earlier quoted context omitted.

Tangent: Homebrew itself doesn’t really choose to take over /usr/local; rather, it just accepts that there exists POSIX software that is way too hard for most machines to compile, and so must be distributed precompiled; and yet where that precompilation implies a burning-in of an installation prefix at build time, which therefore cannot be customized at install time. And so that software must be compiled to assume so…

Or use `/opt` which is a POSIX-standard location. Every managed MacOSX laptop I've gotten from "Big Corp" has had `/usr/local` owned & managed by IT with permissions set to root meaning you're fighting Chef (or whatever your IT department prefers) if you use the default homebrew location.

But again, you'd have that problem whether you used Homebrew or not, as soon as you tried to (even manually!) install the official macOS binary distribution of TeX, or XQuartz, or PostGIS, or...

Homebrew just acknowledges that these external third-party binary distributions (casks) are going to make a mess of your /usr/local — because that's the prefix they've all settled on burning in at compile-time — and so Homebrew tries to at least make that mess into a managed mess.

And, if some other system is already managing /usr/local, but isn't expecting the results of these programs unpacking into there, it's going to be very upset and confused — again, regardless of whether or not you use Homebrew. So it'd be better for those other systems to just... not do that.

/usr/local isn't supposed to be managed. It's supposed to be the install prefix that's controlled by the local machine admin, rather than by the domain admin. Homebrew just happens to be a tool for automating local-admin installs of stuff.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#154

Post by catblast »

saagarjha wrote: post #110
catblast wrote: post #96

Earlier quoted context omitted.

Anybody long enough to remember Unix from the beginning or even just the last 25 years... which is a tiny percentage of this site... should know that a unifying Unix or Unix "tradition" as noted in a follow-up comment is a pretty much a myth. The tradition is whatever system you grew up on and tribal biases you subscribe to and the only true Unix traditions are mostly trivialities like core shell syntax and a handful…

> no X11 XQuartz if you want it > completely non-POSIX low-level API macOS has a POSIX layer.

> XQuartz if you want it

There are X server implementations for Windows, Android, AmigaOS, Windows CE!!, etc... I don't think this is relevant.

> macOS has a POSIX layer. So do many systems, again including Windows in varying forms through the years. I think the salient issue is that BSD UNIX and "tradition" are conflicting. The point of the original CMU Mach project was to replace the BSD monolith kernel.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#155

Post by vlovich123 »

derefr wrote: post #153
vlovich123 wrote: post #134

Earlier quoted context omitted.

Or use `/opt` which is a POSIX-standard location. Every managed MacOSX laptop I've gotten from "Big Corp" has had `/usr/local` owned & managed by IT with permissions set to root meaning you're fighting Chef (or whatever your IT department prefers) if you use the default homebrew location.

But again, you'd have that problem whether you used Homebrew or not, as soon as you tried to (even manually!) install the official macOS binary distribution of TeX, or XQuartz, or PostGIS, or... Homebrew just acknowledges that these external third-party binary distributions (casks) are going to make a mess of your /usr/local — because that's the prefix they've all settled on burning in at compile-time — and so Homebr…

Where are domain admins supposed to put installations?

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#158

Post by [deleted] »

ebg13 wrote: post #117
diggan wrote: post #114

Earlier quoted context omitted.

Hm, do you have any examples handy? It's not that I don't believe you, it's just that in all the years I've been using this, it has always worked. Granted, I'm only using it for reading data, not for saving stuff to /dev/stdin, which would obviously fail.

Anything that seeks, which you can't do on a pipe.

[deleted]

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#159

Post by jdc »

aasasd wrote: post #82

For 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…

also the interactive https://github.com/jmespath/jmespath.terminal
Post reply on HN