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). I hope GNU Core Utilities eventually go the same way or a full-featured alternative appears for Linux that does.

Very nice. This looks like a great complement to `jt` (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.

Also `jq` is awesome - for querying and processing jsons on the command line.

https://stedolan.github.io/jq/

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 -"

?

That's not curl | bash.

That's wget | tar.

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.

`jo` is probably short for 'json output'.

It actually started out meaning `JSON Object'. (Arrays came later. :-)

"JavaScript Object Notation Object"? ;-)

Yes. A JSON Object is not an ATM Machine.

I did wonder a bit what the origin of the name was, thanks for the info.

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

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...

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?

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

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

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

Fork the repository, rename it, only clone from your fork.

    echo 'alias json=jo' >> ~/.bashrc

Or even better

    sudo ln -s $(which jo) /usr/local/bin/json

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.

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?

> 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.

> 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 $?)

Shortest way:

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

I intended True to be, well, TRUE (1). TBH I didn't consider a shell's success (0) as true, though I do see your use-case.

`jo` is conflicting with autojump on my system.

Other than that it looks pretty handy.

    ls | jo -a -B