I like the idea of using blocks as a mini-shell DSL. It allows the language to be fully-featured while also keeping the terse command and pipes invocations that shells are known for. It also makes a lot of right choices like set -euo pipefail by default.
One thing that’s quite powerful with shell scripting that I didn’t see here is that language functions act the same as programs. The doc doesn’t really describe (or I missed it) how to define functions that can be re-used in the command block that would behave like regular programs.
This is the first time I see an attempt to do this. A robust language with all the constructs and unambiguity syntax of general.purpose programming languages,.but attempting a direct syntax for.command invocation.
The documentation is clearly a out this. The choice of inspiration (lua) is a fair one, althou I think something a bit more minimal in terms of delimiters and separators is what people want ultimately.
But I understand it’s not easy to strike a balance. And to be fair, the multi line syntax for commands is well thought through and much more convenient than putting a slash in the end of each line.
Good luck with the project, but please: put the part about command invocation and redirection at the begining of the documentation. All that walkthrough about language constructs, doesn’t set the language appart from all other languages.
Make a cookbook of examples illustrating the killer features.
Hush appears to be very similar to these, except it’s more based on Lua. (At a quick glance it appears to be missing some of the good parts of shell – i.e. that it composes with external processes and the file system.)
A robust language with all the constructs and unambiguity syntax of general.purpose programming languages,.but attempting a direct syntax for.command invocation.
This suffers from the same issue as most “new shell” languages: it doesn’t have a good interactive story. The progress from typing on CLI to pasting together a script is core to why shell scripting is interesting.
So far Xonsh has been something that tries to address both sides. I’m no python fan, but it feels like the right direction.
Obviously different people have different habits and needs, but I don’t need a shell language to have an interactive story at all. When I write shell scripts, I don’t start by typing into an interactive terminal and then move to a script. For me, the start is almost always “I need to run these (5, 10, 50) commands on a whole bunch of files (or directories).” Then I think, “Go is definitely too much, and I don’t want to fiddle with the plumbing required in Python to execute commands, capture stdout and stderr, etc.” For me, a shell scripting language with reasonable defaults and straightforward, simple syntax that makes it easy to run commands is a dream, regardless of whether it has an interactive story or not.
I completely agree as an end goal (I’ve written countless 10+-liners at the prompt just because fish made it easy), but what’s fixable doesn’t doom the language. So I think it’s fine to focus on the language before adding interactivity.
Related: What really needs replacing is not so much bash, but those “minimal POSIX shells” like dash and busybox ash that don’t even support arrays, which makes anything of substance impossible to write correctly. So I would like to see a really minimal but still correctness-conducive language that could actually succeed on embedded. Here, interactive features are less important. I’m glad someone else did it, so I didn’t have to.
Not mine, and I wanted to be a cynical grump when I first saw this on reddit, but I like some of the ideas it’s exploring.
I’m most curious about how its command blocks, error handling, and output capturing will feel in practice. Also curious about its stated functional and object-oriented paradigm support (though I’ll admit, I stopped to post this before actually reading those two…)
I like the idea of using blocks as a mini-shell DSL. It allows the language to be fully-featured while also keeping the terse command and pipes invocations that shells are known for. It also makes a lot of right choices like
set -euo pipefailby default.One thing that’s quite powerful with shell scripting that I didn’t see here is that language functions act the same as programs. The doc doesn’t really describe (or I missed it) how to define functions that can be re-used in the command block that would behave like regular programs.
This is the first time I see an attempt to do this. A robust language with all the constructs and unambiguity syntax of general.purpose programming languages,.but attempting a direct syntax for.command invocation.
The documentation is clearly a out this. The choice of inspiration (lua) is a fair one, althou I think something a bit more minimal in terms of delimiters and separators is what people want ultimately. But I understand it’s not easy to strike a balance. And to be fair, the multi line syntax for commands is well thought through and much more convenient than putting a slash in the end of each line.
Good luck with the project, but please: put the part about command invocation and redirection at the begining of the documentation. All that walkthrough about language constructs, doesn’t set the language appart from all other languages.
Make a cookbook of examples illustrating the killer features.
That means I have failed miserably in marketing / PR
https://ngs-lang.org/
There are many shell languages that have features from general purpose languages like Python:
https://github.com/oilshell/oil/wiki/Alternative-Shells
Including Oil: https://www.oilshell.org/release/latest/doc/oil-language-tour.html
And to pick 3 from the “Python-like” section
https://github.com/abs-lang/abs
https://koi-lang.dev/#fn
https://github.com/alexst07/shell-plus-plus
Hush appears to be very similar to these, except it’s more based on Lua. (At a quick glance it appears to be missing some of the good parts of shell – i.e. that it composes with external processes and the file system.)
What about powershell?
This suffers from the same issue as most “new shell” languages: it doesn’t have a good interactive story. The progress from typing on CLI to pasting together a script is core to why shell scripting is interesting.
So far Xonsh has been something that tries to address both sides. I’m no python fan, but it feels like the right direction.
Obviously different people have different habits and needs, but I don’t need a shell language to have an interactive story at all. When I write shell scripts, I don’t start by typing into an interactive terminal and then move to a script. For me, the start is almost always “I need to run these (5, 10, 50) commands on a whole bunch of files (or directories).” Then I think, “Go is definitely too much, and I don’t want to fiddle with the plumbing required in Python to execute commands, capture stdout and stderr, etc.” For me, a shell scripting language with reasonable defaults and straightforward, simple syntax that makes it easy to run commands is a dream, regardless of whether it has an interactive story or not.
I completely agree as an end goal (I’ve written countless 10+-liners at the prompt just because fish made it easy), but what’s fixable doesn’t doom the language. So I think it’s fine to focus on the language before adding interactivity.
Related: What really needs replacing is not so much bash, but those “minimal POSIX shells” like dash and busybox ash that don’t even support arrays, which makes anything of substance impossible to write correctly. So I would like to see a really minimal but still correctness-conducive language that could actually succeed on embedded. Here, interactive features are less important. I’m glad someone else did it, so I didn’t have to.
Not mine, and I wanted to be a cynical grump when I first saw this on reddit, but I like some of the ideas it’s exploring.
I’m most curious about how its command blocks, error handling, and output capturing will feel in practice. Also curious about its stated functional and object-oriented paradigm support (though I’ll admit, I stopped to post this before actually reading those two…)