I can’t say that I’m a fan of the name “Oils for Unix” for the project as a whole. If you’re gonna rename “Oil shell” the language to YSH, I think it’s still a good idea to keep “Oil shell” as the name for the shell implementation that interprets both the OSH & YSH languages.
In terms of accuracy, there are more parts of the project than OSH and YSH.
When writing YSH / Oil, it becomes pretty apparent that language for DATA are just as important, if not more important, than the shell language (languages for code).
Summary: QSN is moving toward JSON strings, and we’ll also have formats for tables and records.
So those data languages are part of “Oils for Unix”.
There could be other things too. I had to solve the “dev env” problem for our repo (related: Nix, gitpod), and the solution ended up being a mini-distro :-/ ! Or really a bunch of tools to compile from source in containers. I’m not sure if that will be exposed to users, but it’s possible.
mycpp and ASDL (translators to C++) are also things that could be exposed to users in some form.
The shell ends up “leaking” into a distributed operating system project pretty easily :) It’s a language of processes and files, and related tools for working with them.
So I wanted to leave room for other things under the “Oils for Unix” name, not just “Oil Shell”.
In terms of the connotation:
“Oil” reminds people of the energy commodity with the big bad industry behind it. “Oil Shell” further seems to remind people of the company “Shell Oil”. My brain doesn’t work that way, but it’s come up a surprising number of times, over a long period.
Many lobste.rs users are probably past the name by now, and think of it as a shell, but new people are encountering the project every day! There are maybe 10 K lobste.rs readers; there are probably at least 10 M shell users. Shell was the 8th most used language on Github last year, and the 6th fastest growing.
If you Google “Oils for Unix”, it ALREADY turns up our site as the first result. In contrast, “Oil shell” is still polluted by “Shell Oil” after so many years.
YSH is similarly googleable (surprisingly!)
There is a single oils-for-unix binary, which you do NOT type, hence the long name. And there are 2 symlinks, like busybox:
The “Oil Shell” / OSH / Oil scheme has the problem that OSH would naturally stand for “Oil Shell”. So it’s emphasizing the old part over the new part.
In “Oils for Unix”, OSH is just opaque like YSH. (A user suggested “old shell” and “young shell” :) )
I’m actually open to any new suggestions, but I think it will be very difficult to find a name that is different, not taken, accurate, but people already “accept” as the same as “Oil Shell”. (I changed my twitter and Mastodon handle to oilsforunix and nobody noticed.) I don’t want a completely new name like “Zoo” or something.
(edited for clarity, I can see why the original was confusing)
I want to express that I mean this in the nicest way possible. I have tried for years to understand Oil, and have read (possible?) a million words on the subject, and I find that most of the time reading your posts leave me with less understanding than I started with.
The above post also fits this pattern.
I am trying, and completely respect your transparency and willingness to write 1,000 word responses to things, but something just doesn’t click about it all. I wish I had more actionable feedback other than: have you thought about asking someone else to write a succinct overview/survey of where the project sits towards its goals?
To answer this last part succinctly, I’m definitely open to another voice writing about it
There is a lot of dense material on Zulip to summarize, for better or worse, but it’s all there!
Also, you’re probably right that I’ve been “talking past” a lot of people with too many words, which does not lead to a good experience. That’s probably because I’m answering many messages at once, so I’ll take that as good feedback
Hm, some confusion is understandable, because certain things have changed over the years
To be short: we’re changing the name to make the two parts to the project clear:
OSH (compatible shell)
YSH (new shell)
There are also other tools that may fall under the “Oils for Unix” project
The old naming was confusing because people thought “OSH” ? Isn’t that “Oil Shell”? No there’s also another part called “Oil”
It also had a bad connotation for some people.
If it doesn’t click, that’s OK for now … Right now I’m looking for people to test OSH, and to contribute ideas to YSH, which may or may not work out.
A common disconnect is that probably 90% of shell users don’t use the shell as a programming language. I didn’t for the first 10 years I used shell. So a lot of the stuff I write isn’t relevant from that viewpoint.
Some people might also not see the relevance of the writing about grammars and regular languages and so forth. That’s OK, but my response is that the person who developed the first shell is the same person who brought regular languages to computing (Ken Thompson). So part of the project’s philosophy is to really go back to first principles. I think it will show up from the user’s POV, but not everyone will agree.
Hm, some confusion is understandable, because certain things have changed over the years
Of course! That’s why I’ve read millions (potentially?) of words!
Even this post is confusing.
OSH (compatible shell)
YSH (new shell)
Based on previous understanding, I assume “compatible” means POSIX shell compatible. Cool. But, I thought the whole idea of Oil was that it was a new Shell language that would always be lowerable to POSIX shell? So, now there’s a second shell, and that raises questions. Why are there two shells?
The old naming was confusing because people thought “OSH” ? Isn’t that “Oil Shell”? No there’s also another part called Oil
Yes, it’s incredibly confusing. What is Oil? I thought it was a shell. It’s not a shell. It’s two shells, and then a bunch of other things.
The homepage now has a more succinct definition (good!):
Oil is a new Unix shell. It runs your existing shell scripts, and it’s a new language for Python and JavaScript users who avoid shell!
It’s our upgrade path from bash to a better language and runtime.
This is literally soo much more valuable than every other blog post you’ve written about Oil, in my opinion. And, I am still confused by it!
What am I supposed to do with this? I know from it that you’re writing a new shell that is backwards compatible. And I’m enticed to believe that as a new language it’s POSIX shell compatible AND more expressive like Python or JavaScript. But, actually, it’s two different shells, and I have no idea how they work together to leave me in a better position than if I were to have just used POSIX shell, or suffered through writing “shell” code in Python / JavaScript. And, that’s understandable as it’s literally 2 sentences! It’s not enough text to describe everything. But if 2 sentences are already confusing to me, imagine the confusion that might ensue from 100 sentences!
Sorry. I’m trying here. I really am. I’m just consistently failing to understand this project, and I truly do not have this problem with any other project. Even abstract ones. I have imagination, and a whole mess of off the wall ideas of my own. I’m good at understanding and reasoning about abstraction.
Specifically, a bunch of shopt shell options is technically the only thing that differ in OSH and YSH. (You can think of this like from __future__ import in Python – it’s a gradual upgrade when there are minor breaking changes.)
which is equivalent to bin/osh with shopt --set ysh:all – it’s the same binary, with different symlinks!
However, the details may change, so it’s not necessarily stable. YSH isn’t stable either. So I haven’t overly emphasized this point, because some of it’s still aspirational.
However I think it is very interesting, and worth writing about, because 5 years ago most people basically thought it was impossible. It’s definitely not impossible now, because it runs and works.
So I talk about it as two shells, but really there’s blurry line between them that has to do with all the shell options. That’s the “upgrade path”.
I’ll take that as feedback on how I present it
Additionally I’d say it could be confusing because
It’s changed. The upgrade path is no longer based on automatic translation. I wrote some stuff many years ago that is now obsolete. That approach didn’t work technically.
The idea of having 2 shells in one could be inherently confusing. OSH and YSH/Oil are really the same interpreter. BUT if you change a bunch of options, I claim it’s a new language, and that’s surprising.
This whole page is written from the “new” perspective, AND the code parses and runs:
Really there is a hidden “old crappy language” in the background, but I claim it’s all hidden. Some people REALLY want this clean slate perspective, stripped of all legacy.
The project is weird because there are so many perspectives – some people don’t know shell at all, but want a better one. They want something like Python or JavaScript
Other people want “POSIX forever”. We just saw that on lobste.rs the other day
“Oils for Unix” is for both groups, and everyone in between. Just like people who write stuff like Cosmopolitan libc, BSD kernels, Google C++, or Boost C++ – wildly different projects with different dialects – all use GCC and Clang.
BTW Clang handles C, C++, and Objective C all with the same parser. So in that respect it’s very similar. There are C users using Clang that do not know Objective C – I’d say most of them. And there are Objective C users who don’t know C++, etc. Not to mention all the C users who don’t know C++.
So it’s not necessary to understand all of the project in order for it to be useful in some practical way. That is why I talk about “OSH” and “YSH” separately – I’m really talking to two different audiences with different expectations, desires, backgrounds, etc.
I wrote about the change in automatic translation on the blog at some point, and I linked the “OSH versus Oil” page, but I’m not at all surprised that people missed it and are confused :) Ironically, the early readers may be more confused than the people who just started reading, because things have changed.
So yeah the OSH vs. Oil naming is confusing, and the renaming will probably cause a bit more confusion. But I think it will be better in the long run.
I’m going to update the home page sentence as well :) I’m not looking forward to all the churn and renaming, but I think the end state will be much more clear. Again I wouldn’t have renamed it if I didn’t think it was confusing, and if I didn’t NOTICE that people were confused online!
I tried to put all the important info up front in this blog post: OSH is getting done, but it will take a lot of effort to polish it.
YSH is promising, and people have tried it and written code in it, but we still need more help.
There is an upgrade path, but people need to try it and provide feedback on it! It’s possible that nobody really wants to upgrade their shell scripts. Maybe they’re going to rewrite them in Python :)
I know I do though! We have lots of shell scripts that are begging to be upgraded.
I will take this all into account when writing the next blog post :) If you’re still confused let me know
Feedback: I mentioned in my previous response that the succinct 2 sentence thing on the homepage was good! Your reply here is literally 2 pages long.
Thank you for writing it. It did clear up some things! I found most of the other parts to be unnecessary, but did appreciate some of the extra things to think about.
–
Responding more directly to an earlier point you made:
If it doesn’t click, that’s OK for now … Right now I’m looking for people to test OSH, and to contribute ideas to YSH, which may or may not work out.
I think your hypothesis that 90% of people who interact with shell don’t actual program it, seems accurate, but I don’t believe that’s the reason you haven’t found a wider variety of users to test it out and contribute. I think (and btw, I’ve gotten at least 1 private message on Lobsters thanking me for engaging with you like this, and others in another private chat), the problem is that your communication style makes it inaccessible to a large chunk of potential users! Some of those users are probably actually stuck in shell-hell, too!
Shell is a wild place, and so often the right tool for the job. I truly believe a better language for it would be amazing. This is exactly why I’ve read (potentially?) millions of words trying to get to an understanding of Oil.
Yes, thank you apg for bringing this up. I too think Oil is a neat project, but I am utterly lost by what it is trying to be.
the problem is that your communication style makes it inaccessible to a large chunk of potential users
I really wonder if @andyc is too close to the project now. Another engineer, or even better a product manager, explaining things might help improve the signal to noise ratio.
I could have just dropped the link, but I thought I would provide some additional context and analogies
It’s OK if it didn’t help. I do believe there are very concrete benefits now, which I explained in the post, and that there is a path to do something that people thought was impossible 5 years ago
But I fully get that right now it’s not useful yet to many people, and may not be interesting if they’re not using shell in a certain way.
But I fully get that right now it’s not useful yet to many people,
To be perfectly clear. I am not saying that osh or ysh, is not useful. My comment was directed solely on the extra text in your response that went on tangents and clouded the helpful first part of the response.
I know oil isn’t “ready” yet.
Also, thank you for being so open to feedback here. I know it’s sometimes hard to read. It probably would have been better privately, rather than open in the comments as it happened; I acknowledge that and apologize for not seeing it sooner.
i didn’t think of the “shell oil” problem, so good call on moving away from “oil shell”. but “oils for unix” is a seriously clunky name. (that said, i’ll admit i can’t think of too many oil-based names that would not have google result pollution. “snake oil” is tempting due to the python heritage, but no way you’ll get a good search experience with that.)
It’s meant to be a bit long, so it can be available in many global namespaces, like oils-for-unix.org (which I bought),
twitter/oilsforunix etc. Surprisingly “oilshell” has been taken on Twitter for years, for some junk account
It’s also important that you don’t type it! You type the symlinks osh or ysh.
I suggested “oils” as the name for the binary, but then people wanted to type “oils”. So I think the long name is also good in that respect
I definitely agree avoiding the collision with Shell Oil is worth a rename, if for no other reason than that you’ll never out-SEO a major multinational. Is the Unix trademark a potential risk here?
Why have a third oils-for-unix binary? Couldn’t ysh symlink osh or vice-versa? If nobody is supposed to type it why is it possible for typing it to do something?
I don’t think that the name of the tarball is of great consequence. The “Oils for POSIX” project releasing oils-1.2.3.tar.gz makes perfect sense to me.
Where my brain goes after hearing “Oils for Unix/POSIX” is “this is a collection of Oils”, so does this mean OSH, YSH, and QSN are each an Oil? This just seems clunky.
The “Oils Project” or “Oils Collection” doesn’t lead my brain down that path at least.
Also, I want to add that existing languages/projects already have this problem, and you could look to how they name for reference. Rust is a programming language maintained by the Rust Team with a reference compiler rustc (for “Rust compiler”). Nix is a programming language maintained by the NixOS contributors that supports the Nixpkgs package distribution and the NixOS operating system distribution. (I should note that the naming of Nix projects is somewhat notorious; see https://www.haskellforall.com/2022/08/stop-calling-everything-nix.html. Also Nix has a (tiny) standard library, Nixpkgs is/has a standard library, NixOS has a little internal library also called lib, the same as Nixpkgs’s, it’s bad.) Bash is a programming language (descendent of POSIX shell) and a reference interpreter Bash. Same with most shells: Zsh, Dash, mksh, Fish.
Here’s an idea for Oil naming: The project distributes the “Oil Collection” (oil-collection for the multi-call executable), a runtime/interpreter/tool collection for multiple languages/things: the language/shell OSH, the language/shell YSH, and the (data) language QSN. This is no longer just a Unix thing, which is good if someone decides port the Oil Collection to e.g. Redox. OSH is POSIX shell & Bash compatible, YSH isn’t, and they’re related in the Oil Collection implementation but that’s not important right now. QSN is a handy, small data language that’s easy to use from/with OSH and YSH. I don’t have to wonder what “an Oil” is.
I always liked the Oil Shell name & Shell Oil pun. :) Also, I’m not really attached to “Oil Collection”, it’s just an initial idea for a canonical multi-call executable name.
the eval methods mentioned could be a whole post in of itself! I never knew I shouldn’t use unsanitized data with $(()), (()), and [[]], and even more!
Yeah it’s pretty bad, but to boil it down to practice, it hasn’t changed my shell script style that much. Here’s where I use arithmetic:
i=0
i=$(( i + 1 )) # the best way and POSIX way to increment an integer :)
Since loop indices don’t come from external untrusted data, the hidden eval of i doesn’t come into play. If there was a better way to increment indices, I’d use it, but there really isn’t.
Here’s a case where it does come from external data:
cpus=$(nproc)
MAX_PROCS=$(( cpus - 1 ))
Anybody who controls the nproc output can now execute arbitrary shell commands on your machine (with bash and affected shells). But if someone controls nproc, they probably already control your machine. It’s similar to controlling ls or cp, etc. There are a lot of things that have already gone wrong by that point.
On the other hand, data from the network should always be treated as untrusted:
x=$(curl http://untrusted-example.org/user-supplied-number)
echo $(( x + 1 )) # never do this without prior validation
Also, don’t write CGI scripts in shell, at least if you’re using a shell with arrays. Most people don’t do that anymore.
But it will be possible to do safely and conveniently with YSH / Oil.
As mentioned, git repos are a gray area. Most people trust them, but you shouldn’t, and git has a bunch of CVEs that indicate this threat model is important.
I can’t say that I’m a fan of the name “Oils for Unix” for the project as a whole. If you’re gonna rename “Oil shell” the language to YSH, I think it’s still a good idea to keep “Oil shell” as the name for the shell implementation that interprets both the OSH & YSH languages.
The next post is supposed to explain the many reasons for that, but I’ll give the summary here.
First, some readers talked me out of “Soil” a few months ago :) So you might be glad for that
https://old.reddit.com/r/oilshell/comments/x0u7qw/new_names_renaming_for_oil/
In terms of accuracy, there are more parts of the project than OSH and YSH.
When writing YSH / Oil, it becomes pretty apparent that language for DATA are just as important, if not more important, than the shell language (languages for code).
Summary: QSN is moving toward JSON strings, and we’ll also have formats for tables and records.
So those data languages are part of “Oils for Unix”.
There could be other things too. I had to solve the “dev env” problem for our repo (related: Nix, gitpod), and the solution ended up being a mini-distro :-/ ! Or really a bunch of tools to compile from source in containers. I’m not sure if that will be exposed to users, but it’s possible.
mycpp and ASDL (translators to C++) are also things that could be exposed to users in some form.
The shell ends up “leaking” into a distributed operating system project pretty easily :) It’s a language of processes and files, and related tools for working with them.
So I wanted to leave room for other things under the “Oils for Unix” name, not just “Oil Shell”.
In terms of the connotation:
“Oil” reminds people of the energy commodity with the big bad industry behind it. “Oil Shell” further seems to remind people of the company “Shell Oil”. My brain doesn’t work that way, but it’s come up a surprising number of times, over a long period.
Many lobste.rs users are probably past the name by now, and think of it as a shell, but new people are encountering the project every day! There are maybe 10 K lobste.rs readers; there are probably at least 10 M shell users. Shell was the 8th most used language on Github last year, and the 6th fastest growing.
FWIW the original reason for Oil is that it’s an analogy to mechanical systems: http://www.oilshell.org/blog/2019/06/17.html#why-is-the-project-named-oil . i.e. it’s not about energy, but about systems that work well
Importantly, “Oils” has a different connotation than “Oil” (in English). Perhaps similar to “potions”, not the energy commodity
I would suggest a new connotation is what you see in the “Unix Magic poster”: https://jpmens.net/2021/04/09/the-unix-magic-poster/
https://news.ycombinator.com/item?id=27029196
Practically speaking:
There is a single
oils-for-unixbinary, which you do NOT type, hence the long name. And there are 2 symlinks, like busybox:The “Oil Shell” / OSH / Oil scheme has the problem that OSH would naturally stand for “Oil Shell”. So it’s emphasizing the old part over the new part.
In “Oils for Unix”, OSH is just opaque like YSH. (A user suggested “old shell” and “young shell” :) )
I’m actually open to any new suggestions, but I think it will be very difficult to find a name that is different, not taken, accurate, but people already “accept” as the same as “Oil Shell”. (I changed my twitter and Mastodon handle to oilsforunix and nobody noticed.) I don’t want a completely new name like “Zoo” or something.
(edited for clarity, I can see why the original was confusing)
I want to express that I mean this in the nicest way possible. I have tried for years to understand Oil, and have read (possible?) a million words on the subject, and I find that most of the time reading your posts leave me with less understanding than I started with.
The above post also fits this pattern.
I am trying, and completely respect your transparency and willingness to write 1,000 word responses to things, but something just doesn’t click about it all. I wish I had more actionable feedback other than: have you thought about asking someone else to write a succinct overview/survey of where the project sits towards its goals?
To answer this last part succinctly, I’m definitely open to another voice writing about it
There is a lot of dense material on Zulip to summarize, for better or worse, but it’s all there!
Also, you’re probably right that I’ve been “talking past” a lot of people with too many words, which does not lead to a good experience. That’s probably because I’m answering many messages at once, so I’ll take that as good feedback
Hm, some confusion is understandable, because certain things have changed over the years
To be short: we’re changing the name to make the two parts to the project clear:
There are also other tools that may fall under the “Oils for Unix” project
The old naming was confusing because people thought “OSH” ? Isn’t that “Oil Shell”? No there’s also another part called “Oil”
It also had a bad connotation for some people.
If it doesn’t click, that’s OK for now … Right now I’m looking for people to test OSH, and to contribute ideas to YSH, which may or may not work out.
A common disconnect is that probably 90% of shell users don’t use the shell as a programming language. I didn’t for the first 10 years I used shell. So a lot of the stuff I write isn’t relevant from that viewpoint.
Some people might also not see the relevance of the writing about grammars and regular languages and so forth. That’s OK, but my response is that the person who developed the first shell is the same person who brought regular languages to computing (Ken Thompson). So part of the project’s philosophy is to really go back to first principles. I think it will show up from the user’s POV, but not everyone will agree.
Of course! That’s why I’ve read millions (potentially?) of words!
Even this post is confusing.
Based on previous understanding, I assume “compatible” means POSIX shell compatible. Cool. But, I thought the whole idea of Oil was that it was a new Shell language that would always be lowerable to POSIX shell? So, now there’s a second shell, and that raises questions. Why are there two shells?
Yes, it’s incredibly confusing. What is Oil? I thought it was a shell. It’s not a shell. It’s two shells, and then a bunch of other things.
The homepage now has a more succinct definition (good!):
This is literally soo much more valuable than every other blog post you’ve written about Oil, in my opinion. And, I am still confused by it!
What am I supposed to do with this? I know from it that you’re writing a new shell that is backwards compatible. And I’m enticed to believe that as a new language it’s POSIX shell compatible AND more expressive like Python or JavaScript. But, actually, it’s two different shells, and I have no idea how they work together to leave me in a better position than if I were to have just used POSIX shell, or suffered through writing “shell” code in Python / JavaScript. And, that’s understandable as it’s literally 2 sentences! It’s not enough text to describe everything. But if 2 sentences are already confusing to me, imagine the confusion that might ensue from 100 sentences!
Sorry. I’m trying here. I really am. I’m just consistently failing to understand this project, and I truly do not have this problem with any other project. Even abstract ones. I have imagination, and a whole mess of off the wall ideas of my own. I’m good at understanding and reasoning about abstraction.
Ah OK, does this wiki page help?
https://github.com/oilshell/oil/wiki/OSH-versus-Oil
This person was similarly confused, and said that it did: https://news.ycombinator.com/item?id=35201263
Specifically, a bunch of
shoptshell options is technically the only thing that differ in OSH and YSH. (You can think of this likefrom __future__ importin Python – it’s a gradual upgrade when there are minor breaking changes.)But they add up to a new language.
https://github.com/oilshell/oil/wiki/OSH-versus-Oil#full-option-list-in-oilall
The upgrade path is meant to be:
bin/oshshopt --set ysh:upgradebin/yshbin/oshwithshopt --set ysh:all– it’s the same binary, with different symlinks!However, the details may change, so it’s not necessarily stable. YSH isn’t stable either. So I haven’t overly emphasized this point, because some of it’s still aspirational.
However I think it is very interesting, and worth writing about, because 5 years ago most people basically thought it was impossible. It’s definitely not impossible now, because it runs and works.
So I talk about it as two shells, but really there’s blurry line between them that has to do with all the shell options. That’s the “upgrade path”.
I’ll take that as feedback on how I present it
Additionally I’d say it could be confusing because
It’s changed. The upgrade path is no longer based on automatic translation. I wrote some stuff many years ago that is now obsolete. That approach didn’t work technically.
The idea of having 2 shells in one could be inherently confusing. OSH and YSH/Oil are really the same interpreter. BUT if you change a bunch of options, I claim it’s a new language, and that’s surprising.
This whole page is written from the “new” perspective, AND the code parses and runs:
https://www.oilshell.org/release/latest/doc/oil-language-tour.html
Really there is a hidden “old crappy language” in the background, but I claim it’s all hidden. Some people REALLY want this clean slate perspective, stripped of all legacy.
The project is weird because there are so many perspectives – some people don’t know shell at all, but want a better one. They want something like Python or JavaScript
Other people want “POSIX forever”. We just saw that on lobste.rs the other day
“Oils for Unix” is for both groups, and everyone in between. Just like people who write stuff like Cosmopolitan libc, BSD kernels, Google C++, or Boost C++ – wildly different projects with different dialects – all use GCC and Clang.
BTW Clang handles C, C++, and Objective C all with the same parser. So in that respect it’s very similar. There are C users using Clang that do not know Objective C – I’d say most of them. And there are Objective C users who don’t know C++, etc. Not to mention all the C users who don’t know C++.
So it’s not necessary to understand all of the project in order for it to be useful in some practical way. That is why I talk about “OSH” and “YSH” separately – I’m really talking to two different audiences with different expectations, desires, backgrounds, etc.
I wrote about the change in automatic translation on the blog at some point, and I linked the “OSH versus Oil” page, but I’m not at all surprised that people missed it and are confused :) Ironically, the early readers may be more confused than the people who just started reading, because things have changed.
So yeah the OSH vs. Oil naming is confusing, and the renaming will probably cause a bit more confusion. But I think it will be better in the long run.
I’m going to update the home page sentence as well :) I’m not looking forward to all the churn and renaming, but I think the end state will be much more clear. Again I wouldn’t have renamed it if I didn’t think it was confusing, and if I didn’t NOTICE that people were confused online!
I tried to put all the important info up front in this blog post: OSH is getting done, but it will take a lot of effort to polish it.
YSH is promising, and people have tried it and written code in it, but we still need more help.
There is an upgrade path, but people need to try it and provide feedback on it! It’s possible that nobody really wants to upgrade their shell scripts. Maybe they’re going to rewrite them in Python :)
I know I do though! We have lots of shell scripts that are begging to be upgraded.
I will take this all into account when writing the next blog post :) If you’re still confused let me know
Feedback: I mentioned in my previous response that the succinct 2 sentence thing on the homepage was good! Your reply here is literally 2 pages long.
Thank you for writing it. It did clear up some things! I found most of the other parts to be unnecessary, but did appreciate some of the extra things to think about.
–
Responding more directly to an earlier point you made:
I think your hypothesis that 90% of people who interact with shell don’t actual program it, seems accurate, but I don’t believe that’s the reason you haven’t found a wider variety of users to test it out and contribute. I think (and btw, I’ve gotten at least 1 private message on Lobsters thanking me for engaging with you like this, and others in another private chat), the problem is that your communication style makes it inaccessible to a large chunk of potential users! Some of those users are probably actually stuck in shell-hell, too!
Shell is a wild place, and so often the right tool for the job. I truly believe a better language for it would be amazing. This is exactly why I’ve read (potentially?) millions of words trying to get to an understanding of Oil.
Cheers!
Yes, thank you apg for bringing this up. I too think Oil is a neat project, but I am utterly lost by what it is trying to be.
I really wonder if @andyc is too close to the project now. Another engineer, or even better a product manager, explaining things might help improve the signal to noise ratio.
You asked “What is Oil?” Did the wiki page help you understand that?
https://github.com/oilshell/oil/wiki/OSH-versus-Oil
I could have just dropped the link, but I thought I would provide some additional context and analogies
It’s OK if it didn’t help. I do believe there are very concrete benefits now, which I explained in the post, and that there is a path to do something that people thought was impossible 5 years ago
But I fully get that right now it’s not useful yet to many people, and may not be interesting if they’re not using shell in a certain way.
To be perfectly clear. I am not saying that osh or ysh, is not useful. My comment was directed solely on the extra text in your response that went on tangents and clouded the helpful first part of the response.
I know oil isn’t “ready” yet.
Also, thank you for being so open to feedback here. I know it’s sometimes hard to read. It probably would have been better privately, rather than open in the comments as it happened; I acknowledge that and apologize for not seeing it sooner.
Yes. It is a helpful page.
i didn’t think of the “shell oil” problem, so good call on moving away from “oil shell”. but “oils for unix” is a seriously clunky name. (that said, i’ll admit i can’t think of too many oil-based names that would not have google result pollution. “snake oil” is tempting due to the python heritage, but no way you’ll get a good search experience with that.)
It’s meant to be a bit long, so it can be available in many global namespaces, like oils-for-unix.org (which I bought), twitter/oilsforunix etc. Surprisingly “oilshell” has been taken on Twitter for years, for some junk account
It’s also important that you don’t type it! You type the symlinks osh or ysh.
I suggested “oils” as the name for the binary, but then people wanted to type “oils”. So I think the long name is also good in that respect
i wasn’t thinking so much about typing it as simply talking about it. “oils for unix” lacks euphony.
That’s probably true, but I think people might just talk about OSH and YSH ?
(which BTW I pronounce as acronyms Oh-Ess-Aych and Why-Ess-Aych, but you’re free to pronounce however you like :) )
I also say “Oils” when the context is clear. (At least in English, “Oils” has different connotations than “Oil”)
Like the github repo may be oils-for-unix/oils, not oils-for-unix/oils-for-unix
Naming is hard :) Again I’m open to other suggestions, but this name already passed a lot of tests over the last few months …
Fwiw, my American brain goes straight to oh-sh, and yee-sh in the family of cee-sh and zee-sh.
I definitely agree avoiding the collision with Shell Oil is worth a rename, if for no other reason than that you’ll never out-SEO a major multinational. Is the Unix trademark a potential risk here?
Why have a third
oils-for-unixbinary? Couldn’tyshsymlinkoshor vice-versa? If nobody is supposed to type it why is it possible for typing it to do something?I don’t think that the name of the tarball is of great consequence. The “Oils for POSIX” project releasing
oils-1.2.3.tar.gzmakes perfect sense to me.I thought about the trademark, but I think “for Unix” makes it OK ?
Technically the symlinks work like busybox, which has the main binary, and symlinks
I would like all of these to be the same, somewhat inspired by xkcd’s globally unique label:
… and more services, e.g. we are also using Docker Hub, but plan to move off
It annoys me to have slightly different names based on availability …
Suggestions welcome… I will have to make a decision soon, because I can’t blog about YSH/Oil unless it has a name :)
Where my brain goes after hearing “Oils for Unix/POSIX” is “this is a collection of Oils”, so does this mean OSH, YSH, and QSN are each an Oil? This just seems clunky.
The “Oils Project” or “Oils Collection” doesn’t lead my brain down that path at least.
Also, I want to add that existing languages/projects already have this problem, and you could look to how they name for reference. Rust is a programming language maintained by the Rust Team with a reference compiler rustc (for “Rust compiler”). Nix is a programming language maintained by the NixOS contributors that supports the Nixpkgs package distribution and the NixOS operating system distribution. (I should note that the naming of Nix projects is somewhat notorious; see https://www.haskellforall.com/2022/08/stop-calling-everything-nix.html. Also Nix has a (tiny) standard library, Nixpkgs is/has a standard library, NixOS has a little internal library also called
lib, the same as Nixpkgs’s, it’s bad.) Bash is a programming language (descendent of POSIX shell) and a reference interpreter Bash. Same with most shells: Zsh, Dash, mksh, Fish.Here’s an idea for Oil naming: The project distributes the “Oil Collection” (
oil-collectionfor the multi-call executable), a runtime/interpreter/tool collection for multiple languages/things: the language/shell OSH, the language/shell YSH, and the (data) language QSN. This is no longer just a Unix thing, which is good if someone decides port the Oil Collection to e.g. Redox. OSH is POSIX shell & Bash compatible, YSH isn’t, and they’re related in the Oil Collection implementation but that’s not important right now. QSN is a handy, small data language that’s easy to use from/with OSH and YSH. I don’t have to wonder what “an Oil” is.Yes, that’s the idea. Again see the Unix Magic poster – each language/tool is an “Oil”. There may be a lot of them, more than 3 :)
It’s basically like busybox or coreutils.
I think we’re avoiding the Nix problem by calling them OSH and YSH and QSN, not OSH and Oil and Oil Data
I actually mentioned that in the thread back in August where we decided on this name:
https://oilshell.zulipchat.com/#narrow/stream/325160-oil-discuss-public/topic/New.20Names.20.2F.20Renaming.3F
“Oil Collection” is a valid suggestion.
“oilutils” might be another one (similar to coreutils).
However the things that seals “Oils for Unix” is that if you Google or Bing it, it ALREADY points at https://www.oilshell.org/
“Oils Collection” is longer, and less descriptive IMO.
I’m open to more suggestions, but I’ll need to decide soon as it’s blocking the blog. We need something globally unique that will give us all of
I might post a top-level lobste.rs story and see if anyone has feedback
–
I can see why people think “Oils for Unix” is clunky, but if clunkiness is the worst thing, then it’s a pretty good name.
I’m surprised that anyone would go to bat for “Oil Shell”. I thought most people disliked the name :-P
Back in August nobody went to bat for it.
I always liked the Oil Shell name & Shell Oil pun. :) Also, I’m not really attached to “Oil Collection”, it’s just an initial idea for a canonical multi-call executable name.
In any case, it looks like the discussion will be continuing at https://lobste.rs/s/plmk9r/should_oil_project_oil_shell_be_renamed.
the eval methods mentioned could be a whole post in of itself! I never knew I shouldn’t use unsanitized data with
$(()),(()), and[[]], and even more!Yeah it’s pretty bad, but to boil it down to practice, it hasn’t changed my shell script style that much. Here’s where I use arithmetic:
Since loop indices don’t come from external untrusted data, the hidden eval of
idoesn’t come into play. If there was a better way to increment indices, I’d use it, but there really isn’t.Here’s a case where it does come from external data:
Anybody who controls the
nprocoutput can now execute arbitrary shell commands on your machine (with bash and affected shells). But if someone controlsnproc, they probably already control your machine. It’s similar to controllinglsorcp, etc. There are a lot of things that have already gone wrong by that point.On the other hand, data from the network should always be treated as untrusted:
Also, don’t write CGI scripts in shell, at least if you’re using a shell with arrays. Most people don’t do that anymore.
But it will be possible to do safely and conveniently with YSH / Oil.
As mentioned, git repos are a gray area. Most people trust them, but you shouldn’t, and git has a bunch of CVEs that indicate this threat model is important.
Hope that helps!
Thanks for the shout-out :)