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.
Given only 26
/[a-z]sh/names, clashing with a decade-old deprecated project seems ok :)Oilshell has existed long before, AND this project is obsolete based on the readme.
edit to be clear, use the name oilshell. Use
oshas the binary.The
oshbinary is already taken by the omake package.Fair! That’s a much stronger argument given debian (and derivatives) represent a large install base potential.
oilshis short enoughoil-shellis pretty explicit, and probably also fine.It’s got 55 stars. Osh is by no means taken…
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
?
We’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 more appealing now because YSH isn’t stable.
I’m suggesting you just have
oshwhich is oil, the language. All theshopts can be in there if you want, that’s fine. But the goal is to get people to write Oil, the better language, so build a translator,bash2osh, or whatever, to get people into Oil quickly.Cool. Then you don’t lower Oil to POSIX shell. Work on lifting POSIX sh to Oil. If you compare this to
fish, which is fairly popular in my experience, despite it not being POSIX sh compatible, the “legacy to Oil” goes much farther than just abandoning POSIX sh all together.–
Yes, I’m aware that this is a wild departure from what you currently believe is the right path, and who am I? But, this will clear up sooo much about this project, in my opinion, and I’m certain you’d get more people trying it out. You want people to use Oil the language. So, bring people to it. Show them how their current bash-isms are directly translated to better semantics and maintainability, without losing the convenience of shell pipelines.
If it were a lot easier to implement and design a shell, I’d agree that “the goal is to get people to write Oil” (YSH).
But I see the goals as:
Get OSH done and stable. Which means that more people should test it. That seems doable in 2023 if we run enough important, existing shell scripts. (We have run significant ones for over 5 years now, and been through many cycles of user reports)
Get feedback on YSH / Oil. It’s only a prototype now (mentioned in latest post), and there WILL be breaking changes, which is why I haven’t been “advertising” it lately.
It’s true I could just make a translator, ask people to use YSH, and then break a lot of stuff anyway like many new languages, but I’m taking a more conservative approach.
There’s always a fine line to walk with regard to language evolution and breakage. For example Zig is going to break a lot of stuff too, and you see messages/warnings from the creator to that effect. (It’s probably not apparent to people who haven’t written Zig)
I would like things to be done sooner, but the reality is that we don’t have enough people working on Oil. Hence the blog posts soliciting help :) Which have worked to an extent.
I’m OK with the slower pace if it leads to a good result, and that seems to be the trajectory now.
I should also mention that although the translator osh2oil was mostly abandoned for a long time, I did recently revive the code and make it statically typed, which means it translates to fast C++.
But I also cut the scope, and renamed it ysh-prettify. It will do an approximate translation that doesn’t preserve behavior in all cases, because that’s all you can do with syntax.
I don’t think we have the bandwidth to develop or support it now, since we’re still working on Oil / YSH, and the 7 parts of the project mentioned in the post.
But if you’re passionate about the translation aspect, it can use help. (And 3 contributors have been paid a total of 50K euros since last year)
As a concrete example, what are some reasons that this translation wouldn’t work exactly the same?
to
If that interests you, then you might be a good person to work on it.
It has exhaustive tests and demos that run in the CI.
http://travis-ci.oilshell.org/github-jobs/2023-03-21__03-39-43.wwz/
http://travis-ci.oilshell.org/github-jobs/2023-03-21__03-43-38.wwz/_tmp/wild-www/cloud/chef-bcpc/bootstrap/ansible_scripts/scripts/index.html
Also, CoffeeTableEspresso is working toward a big parser refactoring that ysh-prettify depends on:
https://github.com/oilshell/oil/pull/1529
Any kind of prettifier / formatter / linter is a great use case for the busybox binary, so that’s another reason we have it.
I feel like most of your comment is still pretty misinformed, but if you’re interested in the ideas behind the project, the best way to learn is to get involved with the code. It sounds like you read a lot of stuff, but never tried it, which is not really the intention.
Basically every release announcement asks people to try it and send feedback, and suggests ways that they can get involved in the code, or otherwise help the project, e.g. with donations.
I use an alternative (and non-POSIX-compliant) shell called fish. But this isn’t a problem for any of my shell scripts, because they all have a line at the top that says
#!/usr/bin/env bashor whatever.Is it a goal of your project that I should be able to replace
bashwithoshin that top line and have things keep working? It’s not clear to me what value that would provide. Or is that not what you mean by shell script?I think the main answers are:
If you have scripts that are so well-behaved and stable that they’ve already effectively fallen into amber, there’s probably not much value in changing the shebang. If you have living scripts, there’d be some merit in exploring the escape path.
Okay, I think I understand. Oil shell is targeting very large shell scripts written in e.g. bash, and wants to let users swap the shebang without anything breaking?
Yes very large scripts are a main use case for Oil, e.g. this post from 5 years ago, which was very widely read: https://www.oilshell.org/blog/2018/01/15.html (This was with the Python implementation. It worked but it was slow.)
Once you have 1000 lines of bash, it’s a large amount of work to rewrite it in Python. It will probably be 3000 lines then. So we provide an upgrade path.
Again similar to JavaScript -> TypeScript, or C -> C++.
Examples: GCC was upgraded to C++ 20 years after it started. Fish shell was originally C too, and was migrated to C++ maybe 10 or 15 years ago (?)
But I think there’s also value to using OSH for small scripts.
It looks like you replied “yes” to the question “Oil shell… wants to let users swap the shebang without anything breaking?”
Can you clarify this because you just told me in another post that osh won’t run bash scripts that use things like
a=(1 2 3); echo ${a}. So you shouldn’t be selling people on the idea that they can swap the shebang without breaking anything, right?So OSH started out with more intentional strictness, but now we’re “conceding to reality”, as described in the recent blog post: https://www.oilshell.org/blog/2023/03/release-0.14.2.html
e.g. the autoconf example. This could be another one, if more people try it and report what happens. I’ve already gotten some great reports from this release.
So far people seem to think that adding
${a[0]}improves your script, so OSH is helping you by flagging that.If say an important script like stock autoconf relied on it, then the decision would probably be reversed.
It sounds like you should be telling people “you can swap the shebang line, but some scripts will require changes if they violate certain rules designed to improve clarity,” not “yes you can swap the shebang line without anything breaking” which is definitely what @peterbourgon thought you meant.
Or is there a mode that doesn’t impose these rules and aims to be able to run existing shell scripts without restrictions?
And by “flagging that” you mean that it will throw a fatal error and exit, rather than emit a warning?
Yes thanks, that’s accurate!
Yes, you can replace the bash shebang with osh, and you’ll get some benefits now, and more in the future.
I listed a couple reasons that bash or POSIX shell users might want to run their scripts with OSH a few days ago:
https://lobste.rs/s/k4z2qf/write_posix_shell#c_btalnq - more precise error messages, more precise tracing
Another reason is that you can opt into strictness checks with
shopt --set strict:all. I do this in my own scripts:https://github.com/oilshell/oil/blob/master/test/spec.sh#L9
It’s a little like a ShellCheck at runtime, and it’s complementary. ShellCheck finds issues by parsing the script, but it doesn’t have an interpreter, so it can’t look at what happens at runtime.
The final reason is that it’s how you start upgrading to YSH / Oil. First you make your script run with OSH, and then you can start using new features like Python-like expressions, Ruby-like blocks, etc. WITHOUT rewriting it.
https://github.com/oilshell/oil/wiki/Gradually-Upgrading-Shell-to-Oil
It’s basically like JavaScript -> TypeScript, or C -> C++. You don’t have to rewrite the whole program at once.
Can I opt into YSH via an shopt as opposed to needing a seperate binary?
Yes, technically you can run
bin/oshand putshopt --set ysh:allat the top of every main file.However many people want a “legacy-free” shell, so I think
bin/yshis nice. The project is serving multiple audiences.Also, it’s nicer to type
rather than:
and so forth. One-liners are common in shell.
Can I opt into OSH via an shopt in an YSH script?
Yes, with
shopt --unset ysh:allThe 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.
There’s truth to that, but the reason we’re doing things this way is that Unix shell was already regretted 1993 [1], but we’re still “stuck” with it 3 decades later.
Not only that, but it’s was the 8th most popular language on Github in 2022, and the 6th fastest growing language.
So if you want a different result, you have to do something different :)
(Although I’ll repeat again that we support diversity – using POSIX shell forever is a valid way to use “Oils for Unix”. But I’d say more people want to move toward something Python/JS-like than want to learn POSIX shell.)
People who want something simpler can try one of the 30 or so projects here which are not compatible with POSIX or bash: https://github.com/oilshell/oil/wiki/Alternative-Shells
This is a good question, but the answer is that just like GCC and Clang includes C, C++ and Objective C, many different people will be able to use “Oils for Unix” in whatever way they want.
For many years, I’ve heard from passionate readers who want strict compatibility only, and people who want only the new stuff, completely stripped of legacy.
The “jiu jitsu” is that much like Clang/LLVM, we can support both.
Personally, I run my bash scripts with OSH, and then set
shopt -s strict:all 2>/dev/null || trueto catch more errors at runtime. I haven’t upgraded to YSH because it’s not stable yet :)I don’t doubt that people are confused, because I stopped blogging as much because it was uncertain whether we would reach our goals.
Ironically the renaming is to REDUCE the most common confusion :) Namely that OSH == Oil Shell == Oil, which is very understandable.
OSH and YSH makes it clear that they’re different. Ironically, they are actually the same binary, but practically speaking users will use
bin/oshORbin/yshTO START.So yes the naming confusion is DEFINITELY downstream of the project reality. But again the project is designed this way because we’re intentionally doing something different than the 30 other shells on the wiki page.
I believe that calling everything “Oil” is the way the implementer thinks of it – it’s one binary. But calling it OSH and YSH is more user centric – it’s the thing that you TYPE. Some people will use ONLY OSH, and some people will use ONLY YSH. To go back to the same analogy, for a given project, you use only C or “only” C++.
[1] https://www.oilshell.org/blog/2019/01/18.html#slogans-to-explain-the-project
AFAIK everyone calls GCC and Clang just “GCC” and “Clang”. The technical details of the various binaries are somewhat irrelevant.
And now people are calling your project “Oilshell.”
OSH vs. YSH sounds potato-potato, tomato-tomato. I really don’t think it’s a significant movement to being user centric, it’s like 99.9% towards the programmer centric view, 0.1% of the way to the user-centric viewpoint.
I’m not saying you should get rid of both uses–I think it’s good to have choices. But make the choices clearly distinct, and non-confusable.
So you think people will confuse OSH and YSH?
That’s possible, but the confusion is far greater with OSH vs Oil.
Anyway, I need some suggestions – wild ones are accepted, as long as they meet the 4 criteria above. The “no-op” is
which I view as way too confusing.
I think people will not remember whether they should use “o-shell” by andyc or “y-shell” by andyc, and I also don’t think they’ll respect your opinion that
oshandysharen’t abbreviations. If it were me, I’d probably not dwell on the “not shell” angle, as I think it’s confusing.Here’s my best shot:
Also, I’d be tempted make it:
Don’t let those symlinks be an extra distraction.
Or even
osh --posixI 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.oil-sh is a proposed name for what is now called Oil Shell. Took me a while to realize that too…
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++.
Full ack on the obnoxious “legacy” framing. But I don’t see “compatibility” as a negative thing. I mean, the entire reason people would choose the Oil shell over some other shell would be to gradually switch to the oil language, right? As in, the reason Oil exists is its new language.
So having it run in a “compatibility mode” to allow it to run non-oil-language shell scripts in which it is compatible with posix shells and bash makes perfect sense.
Of course, you could also go with
oil-posixandoil-bashas alternative names. Perhaps you can even disable bashisms when invoked asoil-posix. That’d be nice for people wanting to write portable scripts.So there has to be a binary and 2 symlinks, like busybox. It sounds like your suggestion is something like:
or
Is that right?
The project has two related goals:
It’s a gradual upgrade path from one to the other.
Yeah, that’s the idea
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:
That’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 :)
Solution: adopt a crawfish mascot!
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.
Hm yeah that could be a valid concern …
I guess it’s not common knowledge or not clear that Linux, BSD, and OS X are all Unix?
I think for most current readers and experienced OS users, that’s very clear, but it could be a point of confusion for others.
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.
A lot of people do. However, that has been incorrect since 1993.
https://www.theregister.com/2023/01/17/unix_is_dead/
“incorrect” can’t be the right word
Why not?
The word is a trademark. The people who owned the trademark changed the meaning. When a word is a name that is owned by someone, they can change it. They did.
“UNIX” now means “passed Open Group compatibility testing” and it has done for thirty years.
because meaning is not governed by trademarks, but by collective understanding.
https://en.wikipedia.org/wiki/Unix
Not really, no.
2.2 billions Christians absolutely believe that their chosen holy man is the only way to their god. 1.9 billion Muslims absolutely believe that every Christian is wrong and the Muslim’s holy man is the only way to their god.
That’s a lot of people. Who is right? They can’t both be. The one that more believe in?
I’m atheist. There are about half a billion of us, maybe 3/4 of a billion. We think they’re both wrong.
Collective understandings are often wrong. Lots and lots of people believe things that are manifestly not the case.
Unix is a trademark. It belongs to an organisation and because they own it, they get to say what it really means. It used to belong to someone else, and at that time, they got to say what it meant. Then they sold it.
A lot of people missed the news. Doesn’t mean it didn’t happen. It did. AT&T sold it to Novell. Novell kept the code and gave the trademark to the Open Group.
Since that happened, the code and the name are separate things.
A lot of people didn’t notice. That doesn’t mean they are right.
The meaning changed. Again, if people didn’t hear, well, tough, they should pay more attention.
Three decades ago, someone bough the code and kept it. They gave the name away and the new owners of the name chose a new meaning for the name.
This happens.
Before 1993, the phrase “European Union” didn’t mean much. After 1993 it did and meant 12 countries with free trade.
In 1994 it became 15 countries. Same phrase, new meaning.
2004, now 25 countries. Same phrase, new meaning.
This stuff happens. Words and phrases that used to mean one thing then mean something else, because the people who own that term redefine it.
The rest of the world doesn’t get to say “oh well we use ‘EU’ to mean the original 12.” It changed. Move on, let it go, adapt. Meanings change.
UNIX stopped meaning “AT&T code” in 1993 and basically since 1993 “Unix” means “passes POSIX testing”.
If most Unix users have not noticed, then I am sorry but they don’t get to define what it means by some old rule. There is a rule, the rule changed, and it doesn’t mean what it used to mean.
Even if this is shocking and new, well, sorry, this happens all the time.
In 2014 I moved from the UK to the Czech Republic. Lots of my friends thought I’d moved to Czechoslovakia. I didn’t. There is no Czechoslovakia any more. I never lived there, never visited it, and I can’t because it’s gone.
It does not matter if most of the rest of the world didn’t pay attention. It’s still gone.
In 2016 its name in English officially changed to Czechia. Since lots of people still use the old name, well, it’s accepted. It’s the same place. But the name still changed.
What Unix means changed, before many people who use Unix were born, but it still changed.
Lots of protests over preferring the old meaning, or we didn’t notice, or we still use the old meaning, do not affect this.
So if I say “I blew my nose on a kleenex” but I actually used generic facial tissue, you would say I’m “incorrect”?
This whole post is incredible to me I can think of so many counter examples. Meaning is simply not governed by laws. Christians and Muslims granting their religious institutions the power to define meaning is arbitrary, but you granting the same power to the U.S. government somehow isn’t? It’s even more insane than that because the U.S. government makes no claim that trademarks define meaning. No offense meant but I am astounded.
If you want me to go through each of your examples and explain why they don’t justify your position let me know and I will.
So you’re saying “Unix” is genericised, is that right?
that’s not what I’m saying, but it is true
Only got the notif about this right now.
OK. That’s a very strange position to me.
I do not want to be offensive but what this sounds like to me is what the alt-right call “alternative facts”, which to me means “lies that fit our political worldview”.
If I understand you, what you are saying could be paraphrased as:
“OK, so the owners of the name Unix may have redefined it, but that doesn’t matter, because most of us still use the old meaning, which has precedence, and therefore that meaning is more true than the new ‘official’ meaning.”
Is that fair?
No, I never said the owners of the Unix trademark redefined the meaning of the word. It has been genericised the same way “Kleanex” has been genericised, through common usage. At the same time, if I said I think of Kleanex as a particular brand of facial tissue, it wouldn’t be “incorrect” either. Multiple meanings can coexist.
You didn’t say that. I said that. Because it happened, in 1993.
I see where you are coming from, I think. I find it a frankly bizarre position, but OK.
Is my position with regard to Kleanex bizarre, or just Unix?
Oh, just in respect of Unix.
Kleenex, Hoover, Biro… all words used by millions of people, and generic now, agreed.
(Edit: I gather that “Xerox” was genericised for some people decades ago, but not in the dialect of English that I personally speak. I know what it means, but I’d never use it.)
Unix: specific trade term for a relatively small number of weirdo obsessives on the internet, like me. :-)
Loads of people talk about “xNix” and “Unix-like operating systems” and even, gods help us, “GNU/Linux”, but I think that by and large most people know what we’re all talking about when we talk about “a Unix” or “a Unix-like OS”. It seems to me that the actual meaning of the trademarked term was redefined, back when I was about 25, to something closer to what it’s usually used as: to mean something that works enough like a Unix to be compatible with it.
Nobody much is selling anything based on AT&T UNIX™ code any more. Is IBM putting in many new AIX boxes now, or Oracle new Solaris machines?
HP isn’t putting in new HP/UX because nobody makes new Itanium chips any more.
Are there any others at all left?
Xv6 is a maintained port of Unix version 6.
I’m not sure what you’re saying here. The trademark only applies to operating systems which work “well enough like a Unix to be compatible with it” and who have applied for certification from the trademark holder and paid the fee. So I still can’t tell if you have dropped the “trademark defines meaning” idea.
Everything else you said is pretty uncontroversial, but I don’t think any of it means someone is “incorrect” if they think of Unix as an operating system developed at Bell Labs.
I don’t see how I can be any clearer, TBH, and while I appreciate you continuing this discussion, I think we’re spinning our wheels now. You seem to be mixing up who said what.
I have learned from this, and I will remember that.
I would love to see quotes showing that I mixed up who said what. That would mean I misread or misremembered something, and seeing it would let me learn something too, and avoid doing it in the future.
I don’t see the relevance of xv6 being an educational tool, or whether anyone is selling a product with code from Bell Labs Unix. I just mentioned it since you asked.
Example:
« No, I never said the owners of the Unix trademark redefined the meaning of the word. »
You didn’t say that. I said that. :-)
You paraphrased what I said as “the owners of the name Unix may have redefined it.” So I said no, that’s not a fair paraphrase, because I never said that they redefined its meaning:
You asked if it was a fair paraphrase; I responded.
Pinches nose
I was not solely paraphrasing you. I was attempting to précis the conversation.
The ownership of the name did change. Twice. AT&T sold USL Novell. Novell donated the name to the Open Group. The Open Group, which did not own the code and never did (it, or more strictly part of it, formerly promoted a Mach-based OS called OSF/1). So the OG said, roughly, “from now on, ‘Unix’ means ‘passes our compatibility testing’.”
That is what I have been maintaining.
It seemed to me that your position was: OK, that may be so, but the greater Unix community does not acknowledge this and still uses the older definition: that the strict formal meaning of ‘Unix’ is ‘based on AT&T code’.
Better? Is that fair?
Perhaps you can understand why I would not have gotten that, since you wrote “what you are saying could be paraphrased as…”
I don’t believe that trademark holders have the capacity to change the meaning of a word. I don’t think OG believes that either, so no, I would not say “that may be so” to your claim that the OG thought it was changing the meaning of the word “Unix.”
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:
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.
FWIW the history is that Richard Stallman developed GNU in the 80’s, but there was no kernel. So it ran on commercial and closed-source Unix kernels – in particular lots of people seemed to use it on the Sun Microsystems Solaris derivative.
So GNU (standing for GNU’s Not Unix :) :) ) was ONLY used on “Unix”. It was the compiler GCC, the editor EMacs, the coreutils, GNU bash, etc. all compiled and run on top of Unix kernels.
Then Linux came along in the 90’s, and GNU/Linux became more popular than GNU on traditional Unix. But traditional Unix users still use GNU TODAY.
Also, people stopped compiling code from scratch as much, because they had Debian binary distributions so forth.
When you compile open source packages for FreeBSD and the like, GNU bash and GNU make are often build dependencies. They usually call these “Ports” I believe.
Still, I think it’s a great point that people may be confused about “for Unix” vs. “for Linux”, and I would try to address that in a FAQ / announcement.
More on backwards history of Linux / Unix: https://lobste.rs/s/htwiag/ken_thompson_reveals_his_surprising#c_qyqm9o
FWIW I remember encountering GNU as a teenager and being extremely confused about what it is. I think I first saw “copyleft” and GPL and had no idea what it was for like 10 years.
I think the core issue was not understanding how Unix worked – that there is a kernel, and there are user space utiltiies including compilers and shells. Sometimes the kernel and user space are distributed together; sometimes they are separate. (I was a Windows user growing up.)
There is something similar I’ve seen in discussion about Oil. I agree that people are confused, but there’s also confusion due to the underlying subject matter.
I wrote some posts like this, which I hope would help: https://www.oilshell.org/blog/2020/04/comics.html
Another point of trivia: GNU bash was the first program that Linus Torvalds got working on his nascent kernel around 1990-1991.
So GNU bash already existed, and ran on various Unixes. Linux didn’t exist yet.
Thanks for interesting history!
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.
One question I haven’t found clarification about - why does the distribution need to be one binary with two symlinks?
Why not one binary plus one symlink? Or two binaries? Or one binary with an argument?
It seems to really restrict the design space to have to come up with three related names, instead of two.
It’s mainly because it’s set up like busybox, and has been for years. This leaves room for more commands, which we will almost certainly use.
Currently they are
osh oil, and alsotrue false readlink, and we can addtime test, etc.This is confusing. Busybox isn’t a shell.
are you looking for unique names for
truefalsereadlinktimetest, etc? Or are they expected to behave exactly as posix, so no need?Presumably osh/oil will use its own implementations of those commands without traversing the symlinks. Are you expecting users to want to use the oil implementation of those commands while using a different shell?
Yes, that’s a possibility
A minimal readlink was added because OS X doesn’t have it, but it’s useful for
source-ing shell scriptsThe idea of a single binary that lets you gradually convert your shell scripts from one language to another is an interesting one. But tacking on some subset of busybox feels like feature creep and really offends my sensibilities. I guess it doesn’t offend yours, and you don’t seem to mind if a decision seems outrageous to a majority of the people you ask for feedback.
What’s the reasoning behind adding true, false, time, and test? Are there systems that don’t have those, like how OS X doesn’t have readlink?
If someone installs your shell through their distro’s package manager, should they expect symlinks named readlink, true, false, time, and test to appear under /usr/bin?
Really embracing brainstorming here, please read with principle of charity:
Distribute
oilas the interpreter for Oil the language. Name the project Oil or Oil Lang.If that binary can act as a bash compatible drop-in replacement, name that symlink/wrapper
bash. Let package maintainers decide how best to integrate for their distro (saying this as a former package maintainer for a few different distros - Debian, Gentoo, Exherbo, KISS, yocto).If you will be developing many different tools under the same umbrella, name that organization something different. “Oils for Unix” sounds like an organization/team that creates and maintains a few different projects. It would be okay to have oils-for-unix.org point towards oil-language.org and/or other project homepages if you think that is where the current project is heading.
Wow, this is simple, brave, and obviously correct.
I appreciate the suggestion, but yeah I am seeing that the naming confusion is coming from confusion about the project, and about the domain.
It can’t literally be
bashbecause OSH is something different – a cleaned up version of bash, with a gradual upgrade path to YSH.Again, it would be like naming Clang “gcc” – that’s ridiculous.
(BTW If you create a symlink called “bash” to
oils-for-unix, it will ALREADY run like osh. But that can’t be its primary name.)Instead clang and gcc can both be invoked under names like “cc”, and that’s exactly what
oils-for-unixdoes. It can be invoked likeshorbash, in which case it uses the compatible OSH mode.That’s exactly the connotation I want! As mentioned, there is OSH and YSH and serialization formats based on JSON.
Thank you for taking seriously my suggestion and sharing more reasoning about the challenges and inspirations. I had a long written out set of questions, but I think what’s most important is separating out orthogonal challenges:
Clang and gcc have symlinks from cc because they implement the cc interface (with some wiggle room I presume). It would be absurd to have a link named gcc pointing to clang, because clang doesn’t attempt to implement the gcc interface. Does that make sense?
If osh aims to implement the bash interface, then a link named bash pointing to oil would be akin to a link named cc pointing to gcc. I’m not aware of any other shells that have done that for bash, but many shells have done it for sh, even though they don’t exactly replicate the original Bourne shell or POSIX sh. Some Linux distros make sh a symlink to bash, which itself implements the sh interface so that most scripts with #!/bin/sh at the top will run without requiring changes to the code.
What do you mean by “invoked like sh or bash”? Presumably you don’t mean that argv[0] would be sh or bash, since you said you think those symlinks would be ridiculous.
edit:
Note the difference between an organization and a software product developed by said organization. @jedahan was saying it sounds like the former, not the latter.
I don’t think the name is the problem, as much as it is communications.
I seem to be in the minority here, but as someone who has also been forever confused with the project and its past naming, this renaming is the first time I have actually felt like I understand the concept. I honestly like the change as it makes the busybox-like binary clearly distinct from the two symlinks, and does not favour one over the other (as seems to be the intent). The only alternative I’ve seen here that makes sense to me (given what I now understand to be the project goals) is the osh/osh-compat or osh/osh-posix split (it is undeniably more clear).
I actually agree with calvin that the issue is less the naming and more the communication. Part of that is the long history of the project. There have been so many words and I’m still not sure if it’s supposed to be ready for adoption or is still a work in progress. I think people kind of switch off after awhile (I did). But this open discussion is good and it shows that there is plenty of interest in the project, if that interest can only be better taken advantage of.
Glad it clarified things. Honest question: now that OSH vs. YSH is clear (formerly OSH vs Oil), do the “messages to take away” in the latest post give you a picture of the status of the project?
https://www.oilshell.org/blog/2023/03/release-0.14.2.html#messages-to-take-away
I put that section up front because I knew that people were wondering about the project.
I agree it would be great to take advantage of the interest.
As mentioned in the post, we have multiple contributors, including one who has made changes all over the codebase (Melvin).
But a pretty common occurrance is that people get very excited about contributing (and maybe have never contributed to an open source project before), and then they don’t make progress. I think that’s just normal for open source, but I’d be interested whether people with experience think we can do something differently.
In one sense, it’s a Python program on Github, so it should be pretty easy to contribute to.
Another problem I’ve seen though is that a lot of people don’t know shell and just want a better shell. It will be hard to contribute to Oil if you don’t want to know any shell, for multiple reasons.
It does help, I guess from my perspective I’m just waiting until such a time as Oil is ‘ready’ (particularly YSH) to really give it a spin. I did install it for a quick look (OSH). A couple of things were slower than bash but mostly it looks quite polished and I do like the concept. I am optimistic that you will get the project to where you want it to be. Thank you for putting so much work into this.
Perhaps you can solicit feedback specifically from people who know shell. You will obviously need their support for this project to go anywhere.
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 Oil
Notably 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:
https://news.ycombinator.com/item?id=35209556
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:
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.
One example is adding quotes to be explicit, e.g. what does this do?
It can be clearer as:
Adding quotes makes the script more readable and explicit, but doesn’t break compatibility.
Another example is requiring an explicit index when referencing arrays:
OSH:
So writing
${a[0]}or${a[@]}improves the script, but doesn’t break compatibility.Not unless you say so. Zsh literally stands for Z Shell according to the project:
https://zsh.sourceforge.io/
I like “Old Shell” and “Young Shell.” The names describe the tools literally, and the young/old dichotomy seems to be the central theme of the project. Then I would call the project “the Young Shell” with ysh being the main binary and osh linking to ysh. Note that if you have two symlinks pointing to a binary, you will have to decide what happens if the binary is run directly (and of course, what to name it).
It’s way worse than clunky.
It’s actually at the point of being comically bad, which could be a good thing if the goal is to push people away so as to create a small, dedicated community. For that, “Oils for Eunuchs” would actually be great, but I have a feeling that’s not what you’re going for.
The best names often seem strange at first, then grow on people. I think the name Oil Shell has grown on people a good amount, but of course there will still be detractors. I would encourage you to ask the people who disliked “Oil” if they think “Oils for Unix” is a good name.
This is muddled because your replacements change the behavior. Are you saying that OSH is a strict subset of bash, rejecting scripts that include less explicit constructs? If you really meant
are-we-lost?.mp3, would OSH force you to write'are-we-lost'?'.mp3'?You need to have a good way to explain your notion of “compatibility.” It would think it must mean that OSH is either a subset or superset of bash or POSIX sh. I see that it’s not a superset, so you couldn’t just link /bin/sh to osh and expect your scripts to run. Obviously it’s not a subset of POSIX (why mention POSIX at all?). So is it a subset of bash? i.e. if you manually ran
ln -s /bin/bash /bin/osh, breaking the link to /bin/oil, your OSH scripts would still run, yes?I accept most of that feedback – in particular the
oilsforunixvs.oils-for-unixannoyed me on Twitter and Mastodon, since they don’t accept dashes.(Agree WSL is bad, because it should be called “Linux Subsystem for WIndows” :) That is more accurate as far as I can tell )
In any case, I need concrete suggestions of the form of 2 symlinks and binary, like busybox, which is how the project has worked for years:
I view the above as too confusing.
If the
oils-for-unixbinary is run directly, it behaves like busybox – it requires an extra arg.I don’t see the benefit of having two symlinks and a binary which is non-functional when run directly. For busybox it makes sense because there are many tools. Vi and ex were originally hard links to the same binary; in the nvi distribution, nex is a symlink to nvi. This seems much closer to your situation. I feel like there would need to be some tangible benefit to justify taking up 3 names under /usr/bin rather than 2.
I could make more educated suggestions if I understood the project better, such as what you mean by “compatibility.”
Well, oils-for-unix can also be true, false, readlink, etc. :) That has existed for years already. We might add
testlater, maybetime.Is this a way of saying that the only justification is an absurdity?
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
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
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.
${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.)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”:
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.
I wouldn’t allow an obscure technical detail (binary name, symlinks) to decide the name of my project’s brand. Moreover, as you’ve noted repeatedly, ysh isn’t anywhere near ready for release. Why is it a consideration?
You already have your answer wrt. branding, but don’t seem to like it?
My 2c, use one name for everything; oilshell
Oil / YSH isn’t stable, but it’s been released for almost 4 years now. People have written scripts in it, and somebody wrote a VS Code plugin for it.
The project has looked like this for about 4 years:
The “no change option” for the new C++ tarball would probably be
But I view that as too confusing.
My suggestion is
So I’m looking for suggestions of this form.
I believe this form will only increase the confusion in your already confusing brand. 🤷🏾♂️
Stable enough to use as a counter argument but unstable enough to break the binary name? This argumentation feels self-serving.
What happens when someone runs
oils-for-unix?There seems to be considerable confusion about what this project actually is, and this proposal seems to add to that confusion. After reading a bunch of stuff, I think it might all boil down to an issue of nomenclature.
Something described as a shell is widely understood to be a tool, an executable binary, which is designed primarily for interactive use. A shell defines syntax and semantics for its input, and shell scripts certainly qualify as programs. But without other qualifications,
bashis understood to be the binary, not the language that the binary understands.I think when you write shell you are actually describing something that most people would instead call an interpreter. Less like bash, more like Python. Without other qualifications, Python is understood to mean the language, not the binary that interprets that language.
When people see the word shell they understand
bashand notpython. I understand there are many similarities betweenbashandpython, and I understand that a goal of this project for you is to make a shell that’s more like a language. But extending that “blurring of boundaries” into the nomenclature used by the project and its artifacts seems to create a very large barrier for adoption.tl;dr: call the project
oil, the binaryoil-shell, the languageoil-lang, and don’t conflate themYes, I absolutely agree that that’s part of the confusion – most people think of a shell as a tool, not a language.
However I wrote a FAQ in January 2018 that’s been read over 100,000 times (and continues to be read dozens of times a day) that explicitly says that Oil is treating shell as a language.
I updated it in 2021:
http://www.oilshell.org/blog/2021/01/why-a-new-shell.html
As I mentioned on the other thread, 90% of shell users probably don’t do any shell programming, so much of what I write isn’t relevant to them. I didn’t do any shell programming for many years after I started using a shell either.
However, if more people get value out of the project, whether they write shell programs or not, that’s great. If not, that’s also great.
“Oils for Unix” is really a project about a “narrow waist” architecture (Unix-like, Internet-like, web-like) for cloud systems, as opposed to the mess and toil we have today. “Kubernetes is Our Generation’s Multics”, etc.
A side effect of it is producing the most bash compatible shell by a mile, and a path to evolve out of bash toward a language with JSON-like structured data.
This ALSO includes the interactive shell, which is mostly due to Melvin Walls, as mentioned in the latest release announcment. I had put it as low priority compared to the software architecture / language parts, but I’m very glad it was revived.
I get that, and am providing the feedback that this decision seems to be creating a very large barrier to
adoptionedit: comprehension.I want people to get value out of Oil, but the main goal isn’t adoption. As mentioned, my goal is to produce a better shell language, revolving around the “narrow waist’ architecture ideas, which are relevant to cloud systems.
And again, Melvin wanted it to be an interactive shell, so he implemented job control in the last month (very tricky !! And I was definitely not going to do it myself)
So I encourage more people to make Oil what they want it to be, but I don’t consider it my responsibility.
You can even get paid – Melvin was paid a significant amount out of the grant.
Also mentioned in the last blog post: we are continuously improving the dev process and codebase. This naturally came after the shell was translated to fast C++, because before that, there were some “smells” in the codebase.
Some history here:
https://github.com/oilshell/oil/wiki/Where-Contributors-Have-Problems
Ask questions on Zulip if you’re interested, etc. It’s definitely dense, but no questions are rejected or dismissed. The “worst” that will happen is that you’ll be pointed to a FAQ, and that’s perfectly OK
project - Oils
language - Oil
package name -
oilsoroilsh(apt install oils)official interpreter -
oilsoroilsh(/usr/bin/local/oils)the posix script runner -
oils-posixoroilsh-posixas a symlink or wrapper script that sets the correct shoptSeparating out other suggestions to different posts so agreement is not conflated
Thanks for the suggestion
So then taking into account the symlink constraint, the suggestion would be
“Oils” is a valid way to refer to the project. Actually that’s what I wanted originally (since it’s 1 char different than Oil), but I didn’t want it to be a “Go” vs. “Golang” situation.
“Go” isn’t unique enough, so people say “golang”. And then the creators are like “No the name is Go”.
For example, I don’t want it to be “Oilslang”, which is not googleable.
What about
oilruntimeoroilrunfor the executable?oils -> oilrun,oils-posix->oilrun,true -> oilrun, etc. Feels a bit more BusyBox like thanoilshell.Don’t you think it makes sense if
/usr/local/bin/$PROJECTmatcheswww.$PROJECT.organdgithub.com/$PROJECTetc.?Or I guess that’s NOT the thing you type, so you don’t think it should match?
I think at least one of these should be true:
www.$PROJECT.orgetc. matches the busybox-like binarywww.$PROJECT.orgetc. matches the thing you type – bin/osh or bin/yshThe problem is that #2 is impossible, because domain names are globally unique, and Unix names are short
So I think #1 should be true
Feedback?
Regarding the name “Oils for Unix”: the most likely case, I think, is that people are going to mentally skip over the “for Unix,” interpreting it almost as metadata that is not part of the name itself. So you have to ask whether you’d be happy with widespread use of the name “Oils” instead of “Oils for Unix.”
And I think this is less likely, but people might start referring to Oils for Unix as OFU, which could be misinterpreted as text-speak for “oh fuck you.” I don’t think this is, like, a widely-used abbreviation or anything, but “FU” does have a strong identification with “fuck you,” so you can see how someone would make that guess when presented with the unfamiliar acronym OFU.
Yes, actually “Oils” is intended – it’s part of the “jiu jitsu” of renaming without paying the cost of renaming.
I don’t want to rename the project “Zoo” because then people will be confused what project it is. People who know about “Oil Shell” seem to recognize “Oils for Unix” as the same project.
oils-for-unixis the globally unique name. Where the context is clear, we’ll use “oils”, like the Github repository can beoils-for-unix/oils, instead ofoilshell/oil.The title of the future release announcements will likely be “Oils 0.15.0 - Job Control”, not “Oils for Unix 0.15.0 - Job Control”, since it should be clear from the context and domain.
I have thought about OFU as an abbreviation. I didn’t think of the FU part – that might pop into some people’s head, but I don’t think it’s nearly as strong as the Oil / Shell Oil connotation people have.
If I google “OFU”, it doesn’t show up. It’s actually it’s good that OFU has few search results, like YSH.
As another note, many people seem to prefer globally unique names. “Go” is the name of the language, but people call it “golang” because it’s more unique and googlable. Likewise “Oils for Unix” is googlable, but “Oils” or “Oil” or even “OSH” isn’t.
bash++oilandyccorshvmI actually really love
shvm(3) is an odd one for me. I get positive vibes from the petrochemical association; but then I greatly value all the aspects of modern society petrochemicals enable.
all?
Your question made me ponder a bit on the school run today.
I think the answer is: yes, all.
Literally everything that petrochemicals enable is on balance a human good. Medicine, plastics, clothing, cheap and reliable energy, space travel, air travel, … I’ll take them all.
Certainly there are some edges of the fractal that we’d be better off out. Some of the medicines, some of the plastics, etc.
But on balance, I’m going to say “all”. You couldn’t meaningfully prune that tree without losing the valuable branches.
like the aspect of modern society where people are dying from lack of food due to droughts that wouldn’t otherwise happen
I think you’ve been misinformed.
https://www.humanprogress.org/how-humanity-won-the-war-on-famine/
Humans do cause famines; in fact, we’re the only remaining cause of them, in the large. But it’s through warfare, not climate change.
Edited to add: actually, I’d amend that to “warfare or politics”, thinking a bit about Sri Lanka’s recent and tragic own-goal.
so you don’t think humans cause climate change? or you don’t think climate change causes droughts? or you don’t think droughts cause deaths from lack of food?
I fear this conversation is going off the rails a bit; it feels like you’re constructing an array of straw-men for me to choose from - a … straw-syllogism?
Instead, I’d sum my position up as:
Anthropogenic climate change (AGC) is real, and measurable, and has the potential to cause droughts (as well as floods, and other climate events).
The benefits of industrial, commercial, society that derive from activities leading to AGC are massively greater than downsides to (1). E.g. consider the astounding progress documented here: The short history of global living conditions and why it matters that we know it.
Climate events kill far, far, fewer people than they used to.
(2) and (3) rely utterly on petrochemicals. We couldn’t enjoy all of that progress without petrochemicals and the industry surrounding their extraction, refinement, and downstream production.
Per the article I linked earlier, modern famines don’t have their root causes in droughts. Droughts may be a proximate cause; but other factors such as warfare or politics must also be in play and are overwhelmingly to blame.
I will say that (4) isn’t necessarily true. I can certainly imagine an economy driven by nuclear power (or solar / wind / etc. if orders of magnitude improvements to storage are achieved). Likewise, I can conceive of a world where manufacturing processes are re-worked to replace petrochemicals with, say, bio-oils or something.
I’m not at all sold on the cost-benefit of such a change, though, unless it were to happen naturally and (heh) organically. I think the risk of damaging human progress through precipitous mitigations for AGC is very real.
Re. droughts killing people: yes, they do, but in East Africa, not here in Australia. Fixing that problem, not mitigating AGC, would have a much greater ROI in terms of reduction in human misery.
so what was I misinformed about?
I’m going to stop engaging with you now; I don’t believe you’re asking questions in good faith.
classico
Oil is the language
like cpython, Coil is the implementation of Oil in C++
Bash-Replacing Coil is obviously Broil, avoiding the problems with the word Boil
Oils for Unix becomes ’oils for Unix, same branding, same search results
Of course, python based oil implementation is SnakeOil
Thanks, this is probably the suggestion with the best mnemonics and rationale! Broil isn’t bad.
I’d probably still cling to the sh suffix though … that seems pretty ingrained.
There is the tension between the short “coil” name and something globally unique
I think about it as the Go / Golang issue. “Go” is the name, but it’s not unique enough, so people call it “Golang”
Here’s my proposal:
nushp - new UNIX shell project. It’s available as a .org. The only namespace collision appears to be the Northeastern University Student Health Plan, and while there are a bunch of CS people at Northeastern, they are unlikely to be confused.
Call the binary nush. Default it to the new language, version 1.0. If it is invoked by any other name ending in sh, set to bash-compatible mode. If it’s invoked by a name ending in one or more digits, treat it as a version number and go look for the right binary to exec. No python2/3 transitions, please.
Call the data format nushdata. Better version it as well.
When someone asks how to pronounce nush, tell them that if they like it, they can say ‘newsh’, and when they criticize it, they can say ‘nuhsh’.
Thanks for the suggestion! Too similar to http://www.nushell.sh/ though
In X years will be using bash and OP will be contemplating about renaming the shell…