Andy Chu writes about Oils (Oil Shell), a project to build a better Unix shell language and a path off bash.
HN commenters bring it up as a candidate replacement for bash and shell scripting pain, with the author linking it to explain his motivation.
> However, I've never believed it to be possible to have a language both as a shell language and a proper programming language for large-scale projects. I believe the two usecases are fundamentally antithetical, but I'd be happy to be proven wrong.
I'd say Powershell proves you right. Powershell has a great design, it has optional typing and access to a cornucopia of libraries via .NET.
Even so, they had to make some compromises because of the shell parts (functions return output, for example) which makes is quite finicky as a "proper" programming language.
On the shell side, the very nice nomenclature which makes it very readable and discoverable makes is annoying sometimes to use as a shell. That and the somewhat unwieldy launch of non-Powershell commands.
Someone who attempts to bridge the two has a ton of work to do, both in the research and in the implementation department. I guess Oil Shell (https://www.oilshell.org/) is the most realistic approach we have today. And it's probably still 1-2 years away from release and many more years from mass adoption (if that ever happens).
Thinking this is so cool! I was wondering if seriously buying into an alternate shell like this would be worth it in the long run.
Would really love to read from people who use(d) an alternative shell, both success and failure stories.
I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work because you'd then be introducing an implicit dependency on your special snowflake non-standard runtime. Which is something we came to accept and assume for interpreted languages (Python, Ruby, Node, etc.) but I'm not yet ready to assume for shell scripts.
So right when I was going to test Nushell, I discover there are also other shells like Elvish [0] and Oil which supports structured data [1]. Now on top of my hesitations I'm adding decision paralysis :-]
[0]: https://elv.sh/
[1]: https://www.oilshell.org/
Lots more shells: https://github.com/oilshell/oil/wiki/Alternative-Shells
Author here:
Agreed. This is one of my biggest regrets for not following POSIX syntax more closely. So much so that I did at one point start writing in support for inlining Bash (and others) code into murex as a way of allowing users to make use of the rich content already out there. But I couldn't decide on a clean way of implementing it that wasn't any better than `bash -c 'some code'` so ended up removing the feature.
As it is, I'm still half tempted to incorporate a bit more POSIX support to make code sharing easier. But there's a real risk that I could compromise the design goals of my own language in doing so.
I think this is projects like Oil Shell (https://www.oilshell.org/) have the upper hand. It's gone for Bash compatibility plus new features. I have a lot of respect for what they do as it's a much harder undertaking than what I've done.
Turtle [1] is a reimplementation of the Unix command line environment in Haskell that permits you to run external shell commands but leverages the typesystem to provide structured values and reduce errors.
Turtle> cd "/tmp"
Turtle> pwd
FilePath "/tmp"
Turtle> :type pwd
pwd :: IO Turtle.FilePath
Turtle> touch "file"
Turtle> testfile "file"
True
Turtle> rm "file"
Turtle> testfile "file"
False
Fish [2] and Oilshell [3] are two other efforts to create new shell dialects that improve usability while remaining somewhat backwards-compatible.
[1] https://hackage.haskell.org/package/turtle
https://hackage.haskell.org/package/turtle-1.5.22/docs/Turtle-Tutorial.html
[2] https://fishshell.com
[3] https://www.oilshell.org/
shellcheck won't force you to prefer one of the two variants, hence the difference is relatively subtle to a degree that even documentation is not superhelpful either: https://www.oilshell.org/blog/2016/10/12.html
shellcheck will show you many more mistakes that are much more painful your example and also very common.
Deno is definitively an interesting language, but Shell scripting is the gateway to bootstrap so many of your beloved programming languages. If your environment allows it always prefer a proper programming language over shell scripting. Shell scripts are meant for Unix operating system operations, setting few variables, combining certain data-sources, doing filesystem operations, ...
I haven't seen a mention of the Oil Shell (https://oilshell.org) project's OSH/YSH yet and I'm quite surprised.
Oils goal is that OSH is just a new Bash implementation (although not bug-for-bug) but with an upgrade-path to the more modern YSH for real programming with type safety etc, but still as a shell language. One of their exciting ideas is using code as data in a somewhat lisp-like manner to allow function introspection in YSH etc.
Based on other comments it seems like Oil Shell is much more principled in working to actually understand Bash as it exists and presenting an alternative language. I would be interested in what differentiates Amber and whether they have a response to Oils?