
Jo - JSON output from a shell - fcambus
https://github.com/jpmens/jo
======
networked
Neat. An ad hoc alternative to this if you have Python 2.7 handy and can't or
don't want to compile C code could be something like

    
    
      $ python -c 'import json, sys;\
      kv = sys.argv[1::];\
      v = [int(x) if x.isdigit() else eval(x.title()) if x in ["false", "true"]\
          else x for x in kv[1::2]];\
      print json.dumps(dict(zip(kv[::2], v)), ensure_ascii=False, indent=2)
     ' key1 value1 key2 'string value 2' number 5589 boolean1 true boolean2 false
    

which produces the output

    
    
      {
        "key2": "string value 2", 
        "key1": "value1", 
        "number": 5589, 
        "boolean2": false, 
        "boolean1": true
      }
    

I, for one, am excited to hear that native JSON (and XML, and HTML) output is
coming to FreeBSD's userland courtesy of libxo (see
[https://wiki.freebsd.org/LibXo](https://wiki.freebsd.org/LibXo)). I hope GNU
Core Utilities eventually go the same way or a full-featured alternative
appears for Linux that does.

------
dm3
Very nice. This looks like a great complement to `jt`
([https://github.com/micha/json-table](https://github.com/micha/json-table)) -
a tool to turn JSON into plain text tables. Both seem to be super simple tools
written in C with no heavy dependencies.

~~~
r0muald
Snark side comment, jt seems to have one of the worst "curl | bash"
instructions ever:

    
    
        sudo bash -c "cd /usr/local && wget -O - https://github.com/micha/json-table/releases/download/2.0.0/jt-2.0.0.tar.gz | tar xzvf -"

~~~
paulddraper
?

That's not curl | bash.

That's wget | tar.

------
techdragon
Awesome complimentary program to the `jq` tool.

However... I do wish the name was `json` not `jo`. In my case more for
personal reasons regarding painful memories attached to the name 'Jo', but I
also think the tool creates JSON, so why not call it `json` or `jp` short for
'json print' ... but the matter appears settled. Oh well.

~~~
jvehent
echo 'alias json="$(which jo)"' >> ~/.bashrc

~~~
techdragon
Yes I can always do this sort of thing. But it would be nice to not 'maintain
the illusion' when the future day comes that I've got `jo` installed on my
various desktops and laptops, inside containers, on snowflake servers, on
cattle servers, used by a growing collection of shell scripts written for
various versions of sh and bash, etc...

~~~
fiatjaf
I feel the same.

All these smart small tools are amazing, but they suppose the user has only
one computer and does everything on it. so he can just install once and that's
it.

I normally use 4 different desktops and 2 VPSs weekly. Although I tend to do
most of the work in one of the VPSs, the more I customize it with tools like
this, the more all the other computers will miss things.

What is the solution?

~~~
phunge
I found that learning ansible and storing my machine customization as a
deployable playbook was totally worth the effort involved.

~~~
fiatjaf
Does that ansible thing support incremental deploys? Such that installing 'jo'
here will idempotently install it on other machines?

~~~
corobo
Late to the party but yes. The idea behind ansible seems to be (I'm new to
using it) that you can run the command a million times over a million machines
and it'll only install new things to the machines that don't already have it

------
dansimau
Awesome looking tool. One thing I noticed, however:

    
    
        $ false; echo success@$? | jo
        {"success":true}
    

i.e. jo's translation of integers to booleans does not match that of a typical
shell.

~~~
kbd
Because the shell substitutes the return code before passing to jo, jo sees
'success@1'. How do you expect jo to know where the 1 came from to change its
interpretation?

Edit: or you're saying jo should always consider 0 true and 1 false to match
shell return code conventions?

~~~
dansimau
> How do you expect jo to know where the 1 came from to change its
> interpretation?

It was merely an observation. Of course, one can simply negate the value
before passing it to jo.

jo looked as though it was for use in the shell though, so I was curious as to
the design decision here.

~~~
kbd
> It was merely an observation... jo looked as though it was for use in the
> shell though, so I was curious as to the design decision here.

I think it makes sense how it is, since if I typed "success@1" I wouldn't
expect that to output "{success: false}" but I definitely appreciate your
point about a case like "success@$?".

> Of course, one can simply negate the value before passing it to jo.

What's the shortest way to do that? This?

    
    
        echo success@$(test $? -ne 0; echo $?)

~~~
kbd
Shortest way:

    
    
        $ false; echo success@$((! $?))
        success@0

------
zimbatm
`jo` is conflicting with autojump on my system.

Other than that it looks pretty handy.

    
    
        ls | jo -a -B

