New Names for the Oil project and "Oil Shell"?
source link: https://lobste.rs/s/plmk9r/new_names_for_oil_project_oil_shell
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
New Names for the Oil project and "Oil Shell"?
Some people expressed dislike for the “Oils for Unix” name in the recent release:
https://lobste.rs/s/qrbcue/oil_0_14_2_interactive_shell_conceding
The reasons for renaming it are:
(1) OSH vs. Oil isn’t distinct enough; readers are noticeably confused
“OSH” is naturally taken to be a synonym for “Oil Shell”, when really we have two different symlinks to the same binary – bin/osh and bin/oil – which behave differently
/usr/local/bin/
oils-for-unix # real binary, like busybox
osh -> oils-for-unix # symlink
ysh -> oils-for-unix # symlink (formerly oil, not distinct enough)
Important: please read this page for the relationship between the 2 symlinks. That is important so that the naming suggestions reflect the reality of what the project is (which is pretty mature by now)
https://github.com/oilshell/oil/wiki/OSH-versus-Oil
(2) The project now has parts that aren’t “shells”
Including data languages like QSN (which will move toward JSON)
(3) People who encounter the project for the first time often feel a bad connotation of “Oil” and “Oil Shell”, explained in the release comments thread
(4) There are existing “oil” and “oilshell” packages in some distros of the Python reference implementation.
I’d like to standardize on “oils-for-unix” for the new C++ implementation. The C++ one shouldn’t overwrite the Python one suddenly – there should be a gradual transition where both are available.
I’d like the solicit alternatives for the name, and here are some desirable properties.
I’d like a name that is globally unique, hence the somewhat long “Oils for Unix” name. (But you don’t generally type that name – you would type osh or ysh.)
http://www.$PROJECT_NAME.org
http://www.$PROJECT_NAME.org/download/$PROJECT_NAME-$version.tar.gz
$PROJECT_NAME.zulipchat.com/
sudo apt-get $PROJECT_NAME -- and 10 other distros!!
/usr/local/bin/$PROJECT_NAME
github.com/$PROJECT_NAME
twitter.com/$PROJECT_NAME
The thing that sealed the deal for me is that if you Google (or Bing) “Oils for Unix” now, it ALREADY points to https://www.oilshell.org/
It’s a renaming without much of the pain and cost of renaming (although there’s still some). I made a new Mastodon account https://hachyderm.io/@oilsforunix and nobody noticed that it wasn’t called “oilshell”. It’s already a synonym
There was a thread back in August about the new name, on both Zulip and Reddit:
-
Just call it
osh, default it to the better language, and work on a mode that lifts POSIX shell to osh, and lowers to POSIX sh/bash.If the language is good, there’s no reason not to use it. Compatibility, for now, is translating to POSIX, but users get the comfort of shell in
osh.Oil shell doesn’t need the additional complexity of a major rename.
-
The osh named is already taken: https://github.com/geophile/osh. By another shell no less, Object SHell.
-
To be clear, we need a name for 2 symlinks and a binary (and the name for the binary should ideally match the domain name, apt-get name, etc.). So are you suggesting
osh -> oilshell oil -> oilshellWe’re not working on any kind of automatic translation, and it will likely never exist. We abandoned that experiment a long time ago, because it doesn’t really work. Existing shell runtimes can’t support the semantics of YSH/Oil.
There is a historical note about it here: https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#how-can-you-design-a-good-language-on-top-of-shell
Also see this comment in the thread:
https://lobste.rs/s/plmk9r/new_names_for_oil_project_oil_shell#c_tolgcm
A valid use of “Oils for Unix” is to use OSH forever, and ignore YSH. In fact using OSH is much more realistic now because YSH isn’t stable.
-
-
The two related tools with similar names are confusing, I’ve never been able to remember which is which. So I’m a big fan of attempting to simplify the terminology.
At the risk of being a little bit critical, I think this project has suffered from a tendency towards complexity and divided focus, and the confusing names are downstream of that. The new post on data formats strikes me as continuing this tendency: https://lobste.rs/s/qrbcue/oil_0_14_2_interactive_shell_conceding#c_us3r6x.
My own thought: decide what way you’d expect people to use the project. Do you primarily think people will write new things in the new language? Then pick a name for that. Do you think incremental migration from bash to the slightly improved shell using the translation tools is more likely? Then name that.
I assume it’s the former (you hope people will adopt and write in the entirely new language, the compatibility tools are just something that make it a bit easier to move away from sh/bash). Then give the first a nice name “oil”, or whatever. Give the slightly improved version of shell a complicated name: “oil-bash-compat”. On your website, relegate it to the “migration from bash” section.
Your number one problem is that getting people to move off of their shell is very hard. The #2 problem is that people who are interested in #1, and think you have good ideas (I include myself) still find your project confusing. Every time I think about trying it out, the naming and the multiple modes, and everything else give me a bit of an “ugh field’.
Some people might tell you that second problem isn’t a big deal. I disagree. I have read lobsters for years, I’ve read posts on oil/osh for years. I’ve personally thought about writing an alternate shell language. I’m a relatively receptive audience.
P.S. I personally dislike “Oil for Unix”, and think you want a single word that can be the name for your project. That’s secondary to the other points I make.
-
I don’t really see why there has to be a new name. To me it sounds like “osh” is simply a compat layer for “legacy” POSIX/bash/whatever shell scripts. So why not name one
oil-shoroil-compator the like, and the other simplyoil?-
oil-shis too close to “oil shell”, butoil-compatisn’t bad.oil-posix-compateven. -
I want to get away from the “legacy” and “compatibility” framing, because it’s not realistic, and because it alienates people.
No matter what, people will use bash and POSIX shell for DECADES, like they used C for decades after C++ was introduced, and still do today. It can be obnoxious for C++ users to claim that C is legacy, when say the entire Linux kernel is written in C, and millions of lines of C++ libraries are written in C.
We just saw on lobste.rs that there are people purposely writing POSIX shell today, and they are producing useful code: https://lobste.rs/s/k4z2qf/write_posix_shell
Ironically “Oils for Unix” is a great project for them, because basically all that stuff has worked for years :)
It’s a valid use of “Oils for Unix” to use OSH forever, and ignore the other stuff. Just like you can use Clang and GCC without using C++.
-
-
Not sure if this has been raised before, but one problem with “Oils for Unix” is the reaction “Cool, but I’m on a Linux system, so where do I find Oils for Linux?” or ditto for BSD/OSX/WSL/Cygwin.
-
-
I believe I qualify for the latter category, but it’s not clear to me that Linux ∈ Unix. Instead, I think of Unix as the closed-source OS developed by Ken Thompson et al when they wiped the floor with a larger OS effort by introducing the everything-is-a-file architecture, which then inspired many other OSs. So, right or wrong, I think of POSIX and *nix as collective terms and of Unix as something rarely used nowadays.
-
I’d say that’s a strict definition of “Unix” that isn’t wrong.
But I think “Unix” is used in multiple ways.
For example, would you agree that bash is a “Unix Shell” ?
https://en.wikipedia.org/wiki/Bash_(Unix_shell)
Or is bash a “Linux shell” ? It’s the shell I use on Linux.
Would you say “bash is a Unix shell, so I can’t use it on OS X” ?
(honest questions)
-
I read now with small but not big surprise, that Bash is called a Unix shell despite having been developed for GNU and never (I believe?) having run on Unix proper. The article links to the term “Unix shell” with this definition:
A Unix shell is a command-line interpreter or shell that provides a command line user interface for Unix-like operating systems.
which again, comes as a small but not big surprise to me. If, prior to looking this up just now, I had come across the claim “XYZsh is an open source Unix shell with magnificently inventive features”, my first thought would’ve been “I assume they also support Linux so that they don’t severely limit their audience for no good reason, right? Perhaps they even mean *NIX or Unix-like? Gotta verify that before I spend any time on this.”.
I have always understood the term “POSIX shell” to refer to a shell that meets the POSIX standard.
-
-
-
A lot of Linux advocacy over the last 15 years has tried to distance Linux from *NIX and make it seem like its own special snowflake. A lot of people seem surprised that FreeBSD can run most of the same software as Linux because they don’t think of Linux as a UNIX-like thing, they think of it as a not-like-Windows thing or a not-like-macOS thing in its own special category.
-
-
-
I’ve been following the project for quite a while and have disliked the OSH name because it’s an entirely separate language from the Oil shell language - quite confusing! It seems like you want to separate the Oil shell from the New Language that’s kinda like Oil but is also Bash compatible. Not sure if you’ll like these, but here’s what I’ve got:
Oil: new shell language
OilBash: bash compatible shell language that takes ideas from OilNotably the “SH compatibility” is dropped from the name entirely and the focus is on Bash. Although the docs state OSH is both Posix-
shandbashcompatible, it may be worth it to brand it as Bash compatible as many developers who aren’t familiar with the details of Posix compliance won’t know the difference. OilBash may also be more searchable.Another option may be to play off of the Oil name by linking to the oil refinement process. Alternative OSH names could be: Crude(SH), Petrol(SH), Tar(SH), Catalyst Shell
-
Yeah there’s a flaw in that it’s going to be hard to shake the name “OSH” from “Oil shell”. In the new world, both “Oil” and “Oil Shell” are supposed to be gone – it’s ONLY “Oils for Unix”.
OSH and YSH are just acronyms, like ZSH. It doesn’t stand for anything.
(Aside: LLVM has the same problem. It’s no longer a VM, and it’s explained right on the home page, but people still think it’s a VM 15 or 20 years later. The project evolved, just like Oil.)
So I suggested that we can rename EVERYTHING. One possibility:
ysh -> oils-for-unix # new name for POSIX- and bash-compatible shell (formerly osh) yam -> oils-for-unix # problem: yam isn't googlable. (ysh is very googleable)-
Zsh stands for the Z shell (also Zhong Shao).
It’s personally grating for me to read “OSH” and “YSH” and not know whether “SH” stands for “shell,” whether the “O” stands for “Oil,” or what the “Y” stands for. IMO if a word is pronounced as individual letters, those letters should stand for something, or at least have a history of standing for something. I can’t think of an exception (which doesn’t bode well for the few exceptions that probably do exist!).
On the other hand I quite liked the name “Oil” when I first heard about your project years ago. It made me think of the smell of gasoline which I find oddly pleasant. Not to mention it’s short and consists of only letters!
I still feel I’m missing something but it sounds like you want to be able replace other shell binaries without requiring users to rewrite their code. In that case how about just making oil run with strict:all whenever it is envoked as sh? Then users don’t even need to go through replacing #!/bin/sh with #!/bin/ysh.
The feeling of missing something comes partly from this point in the OSH vs. Oil wiki page:
- Improve old scripts while keeping compatibility with sh or bash (strict:all)”
What improvements could you possibly have in mind that don’t require breaking POSIX compatibility? Any such improvement could just as well be made without replacing the interpreter, no? Perhaps this hinges on a special notion of “compatibility”?
“Oils for Unix” is incredibly bad… please don’t do this haha.
-
I don’t follow – so then OSH stands for “O Shell” and YSH for “Y Shell”, just like ZSH ?
I agree some people might want it to stand for something. We thought of Old Shell / Young Shell as a mnemonic, not an official name. There’s also Oak Shell / Yak Shell. Oak gets rid of Oil, and it’s “old and solid as an oak”. Yak is a big yak shave :)
But again, I’m concentrating on what to name the symlinks, binary, domain name, etc. and I don’t think those will be
bin/oakshorbin/yaksh, it wlil bebin/oshandbin/ysh.I’m glad you liked the Oil name, but lots of people felt the exact opposite and hated it.
I think if the worst thing you can say about “Oils for Unix” is that it’s clunky, that’s pretty good.
It’s honestly weird to me that people now want the project to stay “Oil Shell”, because many people said they didn’t like the name.
What improvements could you possibly have in mind that don’t require breaking POSIX compatibility? Any such improvement could just as well be made without replacing the interpreter, no?
One example is adding quotes to be explicit, e.g. what does this do?
stream < are-we-lost?.mp3 # ? is a glob character. does it expand?It can be clearer as:
stream < 'are-we-lost?.mp3'Adding quotes makes the script more readable and explicit, but doesn’t break compatibility.
Another example is requiring an explicit index when referencing arrays:
$ bash -c 'a=(1 2 3); echo ${a}' 1 # confusing: where did the rest of the array go? $ bash -c 'a=(1 2 3); echo ${a[0]}' # more explicit 1$ bin/osh -c 'a=(1 2 3); echo ${a}' a=(1 2 3); echo ${a} ^~ [ -c flag ]:1: fatal: Array 'a' can't be referred to as a scalar (without @ or *)So writing
${a[0]}or${a[@]}improves the script, but doesn’t break compatibility.
-
LLVM has the same problem. It’s no longer a VM, and it’s explained right on the home page, but people still think it’s a VM 15 or 20 years later.
I’m not sure this analogy is on target. Pedantically, LLVM isn’t a VM, but this doesn’t induce confusion in users trying to accomplish a task. I’d rather have it called “Low Level Shell Scripting Language” than have a pair of easily confusable commands.
-
Some sources for that:
https://discourse.llvm.org/t/the-name-of-llvm/21743 (creator Chris Lattner says the name was confusing from day 1)
https://lists.llvm.org/pipermail/llvm-dev/2011-October/043724.html
LLVM isn’t actually a virtual machine. It’s widely acknoledged that the name “LLVM” is a historical artifact which doesn’t reliably connote what LLVM actually grew to be. LLVM IR is a compiler IR.
I still see this confusion. People think LLVM is like WebAssembly, and it’s not.
-
I believe it causes confusion.
However, I do not believe it typically causes confusion for users trying to accomplish a task.[0]
Users need to compile their code, they install clang, they are set. If they are writing a compiler, they use the reference architecture including LLVM (https://msm.runhello.com/p/1003). The confusion is not a significant problem.
[0] Typically is a load bearing term here. I’m confident you can find the occasional person going down a rabbit hole. What I’m claiming is that it’s a small thing, combined with the many many people using
-
-
-
-
-
oil: Oil language shellboil: Bash-compatible Oil shellDoesn’t exactly help with the negative connotations problem, but at least it’s clearer!
-
So then the 2 symlinks and binary would be:
oil -> oilshell boil -> oilshellThat’s definitely a valid suggestion, and I have used “boil” as a name before! Also “Soil”.
But yeah I feel like there are too many negative connotations … I want “boil” to be a verb, but people will read it as a noun because “oil” is. And a “boil” is not a pleasant thing :)
-
-
When people ask for naming suggestions, my mind goes metaphorical — so words like lipid, oil-paint, lube(!), petrol come to me — but in this thread and the one on your previous post I only see people talking about acronyms. So I’m not sure what kind of name you’re looking for.
-
Those suggestions are all valid – wild brainstorming is allowed ! :)
I wanted to go with an “interstitial theme”:
- hay (one component of the project)
All of those things “fill spaces”. The unix shell fills spaces between your binaries :)
Someone suggested “loam” on Zulip and it was just +1’d. (loam is a kind of soil apparently)
lipid is not bad, though we’d need to fit it into “2 symlinks and a binary”, which is how the project works, e.g.
osh -> lipid oil -> lipidosh -> oilshell lipid -> oilshell
-
-
I would keep most of things as-is, I don’t see the point of a full renaming, it just needs some clarity added on homepage and documentation.
- You got the Oil Shell project that regroups everything (I think Oils for UNIX is distancing from what the project is for in the first place).
-
${PREFIX}/bin/oilis the Oil Shell main binary, which runs the Oil Shell with the Oil Language. -
${PREFIX}/bin/oshis the compatibility binary, which runs the Oil Shell with the Oil Compatibility Language which is a POSIX implementation with some additions (like aiming to be compatible with Bash).
I would stop using the uppercase name OSH since it is not clear of what it is referring to. OSH the language would effectively be renamed to “Oil Compatibility Language”. Referring to the binary would need to use the lowercase form osh, and preferably to explicitly refer to it as “osh binary”. Since “Oil Compatibility Language” is too long to write, you could also use “osh language” as a shortcut, as long as you keep being explicit as whether you are referring to the language or the binary.
As to why naming the Oil Compatibility Language’s binary “osh”, it is because it is closer to the name of commonly used shells, which all use the “sh” suffix. While “oil” is a new thing and doesn’t even use this archaic suffix.
PS: If the Oil Shell project starts to aim for the reimplementation of a larger part of what a POSIX operating system is, using the name
Oils for UNIXwould start being more relevant.-
I want to get away from the “compatibility” framing with regard to shell, see this comment:
https://lobste.rs/s/plmk9r/new_names_for_oil_project_oil_shell#c_tolgcm
Also
bin/oilandbin/oshare symlinks – we would still need a name for the binary they point to. (oils-for-unixis my suggestion. In the old Python tarball it’s actuallyoil.ovm, though nobody really knows that.)
-
I don’t think the name is the problem, as much as it is communications.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK