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

Show HN: Jb / json.bash – Command-line tool (and bash library) that creates JSON

github.com

Post reply on HN
Print view View original

11–20 of 56 posts

Re: Show HN: Jb / json.bash – Command-line tool (and bash library) that creates JSON

#11

Post by boomskats »

I find writing bash really gratifying - almost relaxing - but you're right, it also makes me feel kind of 'guilty', especially when I start getting carried away and reading tput docs.

However, I think in your case the rationale in the performance section of your Readme totally makes sense, and every single use case I can think of for this would prioritise minimal latency over increased throughput. I've seen init containers that would execute probably 100x faster with this for the exact reasons you point out. I'm quite curious as to what you would you choose instead of bash if you were starting from scratch now?

FYI Shellcheck has a couple of superficial nits that you might wanna address (happy to send a PR). And your Readme is great.

Re: Show HN: Jb / json.bash – Command-line tool (and bash library) that creates JSON

#13

Post by h4l »

mg wrote: post #6

I like the syntax to send typed values from the terminal: jb id=42 size:number=42 surname=null data:null => {"id":"42","size":42,"surname":"null","data":null} I never had the need to use typed arguments in bash, but if I ever have it, this might be the syntax I'd use. In fact, I was thinking about such a syntax recently. I am writing a tool which lets you call functions in Python modules from the command line. At fir…

Glad to hear, this was something I wanted to make reliable, ergonomic and intuitive. I figured a lot of languages use `: type` to declare types.

The same using jo would be like this, which I find harder to type and remember:

  jo -- -s id=42 -n size=42 -s surname=null data=null
  {"id":"42","size":42,"surname":"","data":null}
Notice that surname comes out as the empty string though, I think this must be a bug in jo!

Re: Show HN: Jb / json.bash – Command-line tool (and bash library) that creates JSON

#14

Post by h4l »

boomskats wrote: post #11

I find writing bash really gratifying - almost relaxing - but you're right, it also makes me feel kind of 'guilty', especially when I start getting carried away and reading tput docs. However, I think in your case the rationale in the performance section of your Readme totally makes sense, and every single use case I can think of for this would prioritise minimal latency over increased throughput. I've seen init cont…

I did find it quite satisfying to coerce bash into doing this while maintaining decent performance. I definitely came to appreciate some aspects of bash more from this, but it's so easy to shoot yourself in the foot!

If I started from scratch now I'd use a compiled language that could produce a single static binary and start with really low latency. I'm pretty sure jo must not be tuned for startup time, if they optimised that they must be able get it way faster than bash can start and parse json.bash. I was pretty surprised that bash can startup faster!

The codebase is basically at the limit of what I'd want to do with bash, but there are features I could add if it was in a proper programming language. e.g. validating :int number types, pretty-printing output, not needing the :raw type to stream JSON input.

Thanks for the heads up on Shellcheck, I'd be happy to take a PR if you'd like to.

Re: Show HN: Jb / json.bash – Command-line tool (and bash library) that creates JSON

#15

Post by sureIy »

enriquto wrote: post #9
mg wrote: post #6

I like the syntax to send typed values from the terminal: jb id=42 size:number=42 surname=null data:null => {"id":"42","size":42,"surname":"null","data":null} I never had the need to use typed arguments in bash, but if I ever have it, this might be the syntax I'd use. In fact, I was thinking about such a syntax recently. I am writing a tool which lets you call functions in Python modules from the command line. At fir…

> I like the syntax to send typed values from the terminal: Incidentally, this syntax shows a notation that is clearly superior to json (at least for non-nested stuff). If all you need is this, you'd be better off by avoiding json altogether. [Rant: if json is so unergonomic that people keep inventing alternatives like this syntax and stuff like "gron" to de-jsonise their lives, maybe using json was always a bad idea…

> shows a notation that is clearly superior to json

I don’t see that at all? Why is `n:number=1` superior to `{n:1}`? If anything, CLI commands are awful for anything other than strings.

Re: Show HN: Jb / json.bash – Command-line tool (and bash library) that creates JSON

#16

Post by simonw »

I found the JSON array syntax a little unintuitive:

    $ jb dependencies:[,]=Bash,Grep
    {"dependencies":["Bash","Grep"]}
One possible alternative would be to accept JSON literal snippets, like this:

    $ jb dependencies='["Bash", "Grep"]'
This should support all forms of nested JSON objects. You could have a rule that if an argument does NOT parse as a valid JSON value it is treated as a raw string, so this would work:

    $ jb foo=bar bar='"this is a well formed string"'
    {"foo": "bar", "bar": "this is a well formed string"}
You could even then nest jb calls like this:

    $ jb foo=$(jb bar=baz)
    {"foo": {"bar": "baz}}

Re: Show HN: Jb / json.bash – Command-line tool (and bash library) that creates JSON

#18

Post by enriquto »

sureIy wrote: post #15
enriquto wrote: post #9

Earlier quoted context omitted.

> I like the syntax to send typed values from the terminal: Incidentally, this syntax shows a notation that is clearly superior to json (at least for non-nested stuff). If all you need is this, you'd be better off by avoiding json altogether. [Rant: if json is so unergonomic that people keep inventing alternatives like this syntax and stuff like "gron" to de-jsonise their lives, maybe using json was always a bad idea…

> shows a notation that is clearly superior to json I don’t see that at all? Why is `n:number=1` superior to `{n:1}`? If anything, CLI commands are awful for anything other than strings.

But strings are often the most common case (or even, the only case that is needed). And they need much less punctuation. Compare:

    a=1 b=2 c=3
with

   {"a"="1", "b"="2", "c"="3"}
the json version needs 19 punctuation characters just to define three variables, against the bash version that only has 3. Which one would you prefer to type with your keyboard?
Post reply on HN