I've seen Oil mentioned here and there, and haven't thought much of it. But this blog is pretty interesting and really shows the effort put into it. I may have to give it a whirl.
Real shame about having to give into the bad eval behavior. I am honestly surprised the project has been able to enable any strictness at all. I assumed any and all bad shell behavior had been utilized somewhere.
(author here) Just to be clear for other readers, we still avoid the dangerous behavior while allowing the (arguably confusing) behavior that autoconf requires.
And this only changes OSH, not YSH / Oil, which is still statically parsed.
It's true that most of the strictness has become opt-in rather than opt-out, but it's still there! So you can choose it if you want.
The Oil language / YSH is basically just OSH, with a bunch of strict options and new features on top (with new syntax)! Surprisingly, that's enough to make it a brand new language.
(author here) The next blog post will explain it, and I'll update the home page, but to be short:
OSH - POSIX and bash-compatible shell. (The most bash-compatible shell by a mile!)
YSH (formerly Oil) - new language with Python- and JS-like data structures, Ruby-like blocks. You can upgrade smoothly from OSH to YSH.
"Oils for Unix" (formerly "oilshell") -- the whole project, which includes OSH, YSH, and data serialization languages based on JSON.
The old names were confusing because the project was called Oil, and it also had a part called Oil. People reasonably assumed those were the same thing.
Also there was "OSH", the compatible shell -- but people reasonably thought that just mean "Oil shell". It's all spelled out on the web site, and in the glossary (both of which I will update), but I understand the confusion.
I look forward to that blog post, I hope that can clear up some of the confusion.
Personally I found that the best introduction for me to actually understand what the different parts do (mainly OSH and Oil Shell) was the Github wiki, particularly "OSH versus Oil" and the two Migration guide posts. Even reading several of your posts, I didn't fully understand what being "an upgrade path from bash" actually meant until I saw the mechanics of how the process would go, and then it all clicked for me.
I think a guided walkthrough of the "upgrade" process would be very valuable to help people understand what the goal is, and would be a good introduction to the project.
I will take your point about walking through the upgrade process. Some things are still not stable so I've been hesitant to "recommend" it, but I think we can just make that clear. Most languages go through a big period of breakages before they get stable
And to be clear OSH is very stable, while YSH isn't. (Next post will also have a list of breaking changes)
I don't mean to sound like a dunce but the naming is very confusing to work out. I've spent an embarrassing amount of time reading the blog posts, glossaries, wiki, and comments and I'm still left a bit confused on the naming choices being the way they are. Part of that may be each explanation tries to teach me about the component in relation the entire project instead of pieces making sense standalone.
Few will gain clarity by an old english meaning of "oils" and "old shell"/"young shell" isn't really gaining many favors in searches even versus the infamous "oil shell"/"shell oil" problem. If it's an extended bourne compatible shell everyone is already used to the pattern of sh, ash, and dash/bash so why not just let osh be "oil shell" as people have already been expecting. Instead of "ysh" it could be something like olang (or maybe oilang, but that's a tougher topic because of the l/ll dilemma) for the programming focused incantation? Searches would be "osh shell" and "olang" just like people Google search for "fish shell"/"bash shell" and "golang"/"ziglang" today.
With osh/olang it's clear what each is intended to focus on, they use existing intuitive naming patterns, search patterns match how people already search about shells, having 2 separate incantations nearly explains itself by name, and you don't need to know about the overall "oils" but when you do the differences already makes sense.
Imagining being asked the following as if I hadn't read a ton on the project already this is how'd I'd answer:
Which of the following binaries are associated with the oil project?
A) osh
B) ysh
A probably, not B.
Which of the following binaries is associated with bash compatibility?
A) osh
B) ysh
Dunno, they both look like shells. 50/50 random guess on each.
Which of the following binaries is used on programs written in the oil language?
A) osh
B) ysh
Dunno, they both look like shells. A) looks like it's related to oil though so maybe that one again.
Now flip ysh for olang...
Which of the following binaries are associated with the oil project?
A) osh
B) olang
A and B both seem likely.
Which of the following binaries is associated with bash compatibility?
A) osh
B) olang
A is named like shells, probably that.
Which of the following binaries is used on programs written in the oil language?
A) osh
B) olang
B about repeats the question back so B, also I'm now doubly sure osh was the bash compatible option in the last question.
I'm not saying olang is the right final answer but the name should first try to make sense THEN try to sound clever. "ysh"/"soil" lack any self description and require you already know what they do to understand the name instead of the other way around.
Something like ysh and yam seems great as well, assuming ysh then means yam shell and the overall project name is related to yam in some way. I don’t have a better “rename everything” name in mind though, hard to say without a good understanding of the other components.
One thing to consider is you kind of get 1 “nonsense” pass in that you can really pick anything as the project name long as everything gets named in relation. E.g. hardly anyone knows rust is named after the rust fungus because it’s hardy but everyone gets that rustc is the compiler, rustup updates rust, .rs and .rlib are the file extensions, rust lang refers to the language in particular, and the community makes tons of rust related name puns from there. Oil was actually a really solid option for that kind of base beyond the connotation often being negative.
First time I hear about oil shell. Funny name, but that aside, I have a hard time taking a shell seriously that started out written in python. They describe it as having "python-like types", interesting. And they say it's a shell targeted at people who "write scripts, which may get into the hundreds or even thousands of lines" rather than end-users. If you write complex scripts, please use a proper language. Also, I've been writing "complex" bash scripts since ages, and of course it can be somewhat annoying with bash's quirks. But it runs almost everywhere without extra dependencies, which is the main reason I use it. If I had to install oil on all machines running my scripts, why wouldn't I go ahead and use rather go and distribute binaries? Well, my guess is this will never catch on.
