> Idio is a programming language for orchestrating commands like a shell. It is asking the question, can we write better shell scripts by integrating shell-like constructions into a programming language?
I think the answer is "no" :-).
I suspect it would be "better" to have shell programs read parameters in a popular semi-structured format like JSON. Orchestrating commands would then be about creating a tiny bit (or a lot... ehem... say, ffmpeg anyone? :-p) of JSON in any way one likes.
Then we could do something like: `system("ffmpeg", someJsonParams)`
Perhaps we could prototype something like this on top of busybox [1]:
* Make it so all parameters to all commands can be provided with a JSON blob.
* The output would be JSON itself too, so we won't have to do silly things to parse it.
* Things like progress and debug output could go to stderr so we can still have percent progress bars and other nice things like that.
* When piping output in some shell, we could use msgpack or some other JSON encoding to avoid having to lex and parse all the time.
* If a program doesn't provide these features, it could be wrapped by some "launcher" program that would do the cmd-line-to-JSON and output-to-JSON transforms.
* A shell could always try to do some pretty-printing as last step in some generic way, thus a human would not have to read JSON output all day long :-).
Augeas does something like this but for config files, kind of a related concept I think: "It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files." [2]. one could think of input parameters as an additional config file, or a file coming from std in. For augeas, everything is a tree though, in its own defined format.
There is at least one attempt to solve the "make shell output JSON" part of the problem. I think I've seen others, but this is the only one I can recall:
nushell and powershell use the concept of "output as typed data".
nushell has typed parameters as well, but nushell fell over for me where the built ins didn't provide some simple functionality coreutils do (admittedly a while ago now)
I'm sure I've run into a project (in python?) that wraps common gnu utils for json output like you describe as an interim step for command that don't support a `--output=json` like option. My search-foo is failing me though...
Note to self: don't hold yourself hostage to Betteridge's law!
I wouldn't disagree but it's quite a jump from where we are today to an execvj(path, json) and whatever form retrieving/reconstructing the structured data would take.
I'm starting from an easier position. Change things a little bit. :)
Yes, regular job control is available interactively.
Note that I'm interested in making scripting work better so I've made little to no attempt to ease interactive use (there are plenty of better alternatives for interactive shells).
I tend to use "rlwrap idio" to make editing easier.
There's a lot of Scheme-ish things available: setters, templates (aka macros but with changeable quoting: ` ' @), continuations.
I've added a few more tricks: computed variables (like SECONDS or RANDOM which dynamically get/set a value) and reader operators (which are the heart of infix "functions" and get to rewrite source code expressions, | being the obvious one for a shell).
All available to the user -- nobody wants to be writing stuff in C! :)
It's from the Greek 'idios' meaning own, private. From that the etymology suggests ignorance and from that low intelligence giving us the modern derivation of idiot (and any attendant socio-cultural associations).
Here I'm using it in the sense of doing my own thing where I'm not feeling particularly bound by how other shells work.
You do you. Just pointing it out in case it hadn't occurred to you. I can't say how likely people are to interpret "Idio" one way or the other, or how important it is to you. It is your project, after all. (I don't mean this comment to be antagonizing...)
I suspect it would be "better" to have shell programs read parameters in a popular semi-structured format like JSON. Orchestrating commands would then be about creating a tiny bit (or a lot... ehem... say, ffmpeg anyone? :-p) of JSON in any way one likes.
Then we could do something like: `system("ffmpeg", someJsonParams)`
Perhaps we could prototype something like this on top of busybox [1]:
* Make it so all parameters to all commands can be provided with a JSON blob.
* The output would be JSON itself too, so we won't have to do silly things to parse it.
* Things like progress and debug output could go to stderr so we can still have percent progress bars and other nice things like that.
* When piping output in some shell, we could use msgpack or some other JSON encoding to avoid having to lex and parse all the time.
* If a program doesn't provide these features, it could be wrapped by some "launcher" program that would do the cmd-line-to-JSON and output-to-JSON transforms.
* A shell could always try to do some pretty-printing as last step in some generic way, thus a human would not have to read JSON output all day long :-).
Augeas does something like this but for config files, kind of a related concept I think: "It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files." [2]. one could think of input parameters as an additional config file, or a file coming from std in. For augeas, everything is a tree though, in its own defined format.
1: https://busybox.net/about.html
2: https://augeas.net/index.html