Our great sponsors
-
oil
Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
(author here) I don't think anything you wrote should be a surprise to regular readers of the blog. Many of my blog posts in the last year say "the scope of the project is too large" and similar stuff.
http://www.oilshell.org/why.html#why-not-use-it
It might be a surprise if you're only reading what shows up on news aggregators. But to be clear, I basically write about what I'm thinking, what progress has been made, etc. And the main purpose is to get people to test out the shell, and attract developers who want to push in the same direction.
It's been working, as I've gotten a lot of valuable feedback and contributions on both OSH and Oil. But I can use more.
Oil is NOT a "product" which you can download and use. Right now it's better for say people who have the desire and ability to make it through the quick start for contributing:
https://github.com/oilshell/oil/wiki/Contributing (how to get a working bin/osh from git in 30 seconds on most Linux distros)
----
The "summer blog backlog" has some project status updates that aren't out yet, but I'll give the tl;dr version here.
There are roughly 5 equal sized parts of project, all large:
1. The compatible OSH language (mature, not buggy, but not fast yet)
Thank you for the extensive and thoughtful comment! This does help clarify your approach quite considerably. I wonder, since you are hoping to attract collaborators, whether there is some kind of formal spec for the language somewhere? For example, you mentioned parallel efforts: suppose I wanted to write a port to pure C; is there any way, short of reading every one of your posts and trying to contain the whole language in my head at once, for me to know exactly what I need to implement?
Something I've been trying to figure out: what is the exact relationship at present between OSH and Oil? When you say "OSH" do you mean the language, or the shell itself "oil shell"? If Oil is not something I can download, why exactly does that `const v = max(1, 2)` statement work in osh? It's clearly not just a Bash implementation, it's got other features. Is that a subset of Oil's features? Which subset?
Since you're also interested in other shells, you might have a look at pyp [1]. It captures a lot of the way I personally would like to use some future shell. If the features of pyp were integrated into the shell itself, you wouldn't need an external command, you could just (for example) pipe the output of one program into a python-like statement that mangles the incoming strings in some way, and pipe that out to some xargs-like program to use in a subshell. (The fact that you apparently can't use the pipe in what Xonsh calls "Python mode" is for me the central limiting feature of that shell.)
Related posts
- Easily handle CLI operation via Python instead of regular Bash programs
- Modern Linux Tools vs. Unix Classics: Which Would I Choose?
- Shshsh is a bridge connects Python and shell
- GitHub - python-cmd2/cmd2: cmd2 - quickly build feature-rich and user-friendly interactive command line applications in Python
- State of Object Oriented Shells for *nix