41–50 of 56 posts
{"password":"hunter2"} A man of culture I see. This looks really useful where you don't want to introduce another scripting VM just to spit out some JSON, i.e I have used Ruby a lot for this in the past. I can see myself using this in container init scripts and other very low dep environments to format config files from env vars etc.
Yeah if you need this it's definitely a sign you shouldn't be using Bash. Can you give a concrete example of when this is the sanest option?
Two main situations I think. The first is just interactive use in any shell to encode ad-hoc JSON. If you have a next-gen shell which can handle structured data directly, then you probably don't need it. Second is situations where you'd rather not add an additional dependency, but bash is pretty much a given. For example, CI environments, scripts in dev environments, container entrypoints. Or things that area already…
Is this tool not an additional dependency?
> But bash is just really ubiquitous
Biggest crime of the Unix world probably.
This is incredibly high-quality BASH programming, as a fellow bash freak I am studying this code, and even I am learning some new techniques. https://github.com/h4l/json.bash/blob/main/json.bash You've boiled it down to a set of very elegant constructs. Respect. Thank you @h4l, this is badass. I hope you follow up with a golang or rust implementation, that would really be something else. p.s. I noticed the following…
Thank you, that's high praise! I learnt a lot about bash writing this, but I've also not looked at the code in a few months, and it's already starting to look quite intimidating! I definitely like the idea of a goland/rust implementation, there are certainly things I could improve. So the argument syntax escapes by repeating a character rather than backslash. I chose this because with backslashes escapes it would be…
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.
%{n:1}
I’m sure you can do similar things in other modern shells too. So the real problem is that people are stuck on the constraints of 1970s command lines.
Yeah if you need this it's definitely a sign you shouldn't be using Bash. Can you give a concrete example of when this is the sanest option?
Two main situations I think. The first is just interactive use in any shell to encode ad-hoc JSON. If you have a next-gen shell which can handle structured data directly, then you probably don't need it. Second is situations where you'd rather not add an additional dependency, but bash is pretty much a given. For example, CI environments, scripts in dev environments, container entrypoints. Or things that area already…
But for when you don't want an extra dependency, awk and perl are better than bash and just about as ubiquitous. (I might dare to say more ubiquitous, since MacOS in particular ships with an ancient version of bash that can't even use this jb tool. But the versions of awk and perl it comes with are fine.)
{"password":"hunter2"} A man of culture I see. This looks really useful where you don't want to introduce another scripting VM just to spit out some JSON, i.e I have used Ruby a lot for this in the past. I can see myself using this in container init scripts and other very low dep environments to format config files from env vars etc.
As a user, I’m fine with embedding a reasonably small VM to handle the configs; disk space is cheap. Better yet would be a compiled binary that handles it, but that feels like asking a lot of maintainers.
There’s a lot of surface area for someone to mis-quote stuff in their environment and generate unintelligible bash errors.
Or that may be just me; I hate bash in general, so maybe it’s just that bleeding over.
Earlier quoted context omitted.
Thank you, that's high praise! I learnt a lot about bash writing this, but I've also not looked at the code in a few months, and it's already starting to look quite intimidating! I definitely like the idea of a goland/rust implementation, there are certainly things I could improve. So the argument syntax escapes by repeating a character rather than backslash. I chose this because with backslashes escapes it would be…
How is this different to this https://github.com/kellyjonbrazil/jc
jb doesn't have high-level knowledge of other formats, it can read from common shell data sources, like command-line arguments, environment variables and files. It gives you ways to pull several of these sources into a single JSON object.
jb understands some simple/general formats commonly used in shell environments:
- key=value pairs (e.g. environment variable declarations, like the `env` program prints
- delimited lists, like a,b,c,d; (but any character can be the delimiter) including null-delimited (commonly used to separate lists of file paths)
- JSON itself — jb can validate and merge together arrays and objects
You can use these simple sources to build up a more complex structure, e.g. using a pipeline of other command line tools to generate null-delimited data, or envar declarations, then consuming the program's output via process substitution So jb is more suited to creating ad-hoc JSON for specific tasks. If you had both jc and jb available and jc could read the source you need, you'd prefer jc.
Earlier quoted context omitted.
Two main situations I think. The first is just interactive use in any shell to encode ad-hoc JSON. If you have a next-gen shell which can handle structured data directly, then you probably don't need it. Second is situations where you'd rather not add an additional dependency, but bash is pretty much a given. For example, CI environments, scripts in dev environments, container entrypoints. Or things that area already…
> Second is situations where you'd rather not add an additional dependency, but bash is pretty much a given. For example, CI environments, scripts in dev environments, container entrypoints. Or things that area already written in bash. Is this tool not an additional dependency? > But bash is just really ubiquitous Biggest crime of the Unix world probably.
It is, but if you already have bash, adding another shell script isn't much of a jump. e.g. I'd feel OK about committing jb to another repo for use from a .envrc file to set up an environment, whereas committing a binary would not feel good.
> Biggest crime of the Unix world probably.
Sorry if I'm perpetuating this! :) My take is that problem is not with bash, the problem is that it's hard for more advanced tools to replace it.