_flux
4 days ago
I realize it's nice to use short names for applications, but couldn't this also be have been called jdiff? I feel like the two-letter tool name is exercising developer memory more than strictly required. I have 42 two-character binaries in /usr/bin. Of course, that's still only about 5% of the available two-alphabet names..
The developer can always choose to use a shorted local alias for commonly used tools.
That being said, I wonder if this is much better than difftastic that is more general purpose, but tree-aware? I suppose this one wouldn't care about JSON dictionary key ordering, at least.
keybored
4 days ago
The real headscratchers are the tools that have a proper name, a shortened name, and a command name:
- Stacked Git
- Shortened: stgit
- Command: stg
Lots of “stgit: command not found” ensues.
mejutoco
4 days ago
You have a point of course, but I find it funny that the path is not /users/binaries and, instead, it is a similar abbreviation.
In a way, it is a sort of seo race for tool devs.
spencerchubb
4 days ago
usr stands for user system resources
Tsiklon
4 days ago
This is a backronym. /usr is the original user home directory location on classic unix.
conkeisterdoor
4 days ago
TIL after so many years that /usr isn't an abbreviation of "user". "UNIX/user system resources" makes a lot more sense in retrospect. Guess I should have RTFM a long time ago!
dunham
4 days ago
It looks like that's a newer interpretation than the original:
> As such, some people may now refer to this directory as meaning 'User System Resources' and not 'user' as was originally intended.
https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.htm...
josephburnett
4 days ago
> couldn't this also be have been called jdiff? I feel like the two-letter tool name is exercising developer memory more than strictly required.
Yeah, in retrospect I should have given this a longer name. I was going for a natural fit with `jq`. ¯\_(ツ)_/¯
> I wonder if this is much better than difftastic that is more general purpose, but tree-aware?
There are quite a few good tree-aware JSON diff tools out there. But I wanted one that could also be used for patching. I've tried to maintain the invariant that all diffs can be applied as patches without losing anything. And I also wanted better set (and multi-set) semantics, since the ordering of JSON arrays so often isn't important.