I've probably been using fish shell [0] for close to 10 years now. When I need POSIX compliance or if I need to run a one-off bash command, I just call bash. It's exceedingly rare.
Browsing through the documentation for Oils, it seems to be organized in a way that's very confusing. When you open the fish shell website it was two clear buttons for Tutorial and Documentation.
I've been using OhMyZsh in all terminals for years which seems pretty active and auto updates fine whereever I'm using it, e.g in Linux, macOS, Windows/WSL. Zsh might have a slower release cadence but I'm really happy with my with Oh My Zsh setup and don't feel like I'm missing anything.
The one area where I've stopped using bash/shell is in complex shell scripts which I'm now writing in TypeScript and executing with Bun by using: #! /usr/bin/env bun
> The one area where I've stopped using bash/shell is in complex shell scripts which I'm now writing in TypeScript and executing with Bun by using: #! /usr/bin/env bun
(blog author here) This is exactly what's wrong with bash (and zsh). It should NOT be hard to write a bit more complex scripts. But it's so ingrained into our heads that shell is "too hard" that people use ts/js/python/etc. And usually the UX to writing "glue code" is much worse than with a good shell like Ysh.
I really do like these kinds of posts. I like the author’s passion. Will check oils, radicle, and simplex out. Though I think getting my wife to try simplex over iMessage is unlikely to happen hah
Signal has the same thing as Simplex. You can change your user ID at any time, and the only thing that does is that the old ID can't be used to find you.
Thanks for the great write-up—Radicle and Simplex Chat look awesome, and I’m looking forward to checking them out!
One tool that recently gave me that "this is how it should work feeling" was Flighty (iOS flight tracking). The UI, functionality, and flow felt so seamless—it was like music to my technophile ears. I wasn't even expecting much, because it was like "meh, its a flight tracker." But, it really wowed me.
I always justify my tool obsession by saying that after installing thousands of tools and apps, you become a naturally good product manager. Because you have a high bar for quality and during the planning/mockup phase you have lots of patterns in your head of what great looks like.
There is no way out of traditional UNIX shells, because most folks don't control the servers, and getting snowflake shells being adopted across the company and customers hardly works.
Also there are many UNIX deployments, where bash still isn't a given, one might be surprised with tsch or ksh.
(blog author here) That is the kind of thinking which just unnecessarily gatekeeps innovation.
There's always someone "in control" of a server. But even more important, there's always someone (or usually a group) in control of deciding which shell should be the default on an OS. And these are the people that should be reached somehow.
And Oils is just as much a snowflake as Bash, Tcsh or Ksh. All of them are POSIX compliant (though not sure with tcsh), all of them bring own additional features. But the only shell with additional features which don't suck (by being 30yo) is from the Oils project.
You are right in the sense that Clang never replaced GCC on say Debian or Red Hat. As far as I remember, there are only a couple minor distros and one BSD that use Clang as the default.
So even though Clang is extremely compatible with all sorts of GCC quirks, inertia is still strong
And to probably 90% of people, Clang does the same thing as GCC. Probably 90% of people couldn't tell the difference between the two
But I think many people are glad Clang exists, e.g. it pushed GCC forward (at least in error messages, in modularity, and probably more)
And some people use ONLY Clang, not GCC
---
On YSH, most people do think there needs to be a "clean slate" successor language to shell, and that's what YSH is aiming for. Notably, it's informed by re-implementing almost all of bash from scratch, and shares the same runtime
The reasoning behind that is that I noticed that sort of like "make replacements", many alternative shells [1] are better in one dimension than their predecessor, but worse in other dimensions.
Our goal is to be better in all dimensions, so a superset is a good way to achieve that. We learned the hard way that these 30-, 40-, 50- year old tools have very diverse users and usages - i.e. most people might use 10% of the features, but across all users, that's 100% of the features
Nonetheless, OSH has been the most bash-compatible shell, by a mile, for a few years, and it's only getting more compatible. How fast it converges depends on contributions, and we're getting good PRs, but can always use more
YSH also has a bunch of users that are providing great feedback, and helping to make it stable
bash, ksh, zsh and a few other shells have the awesome feature that if you call them with a link named "sh" they accept Posix Bourne-shell syntax.
This means you can make them your /bin/sh system shell which will be used to log you in and your login scripts can then set environment variables for your whole session. This feature is something I count on.
Some system shells (not dash) also allow login scripts to export essential shell functions to the session environment.
I would love to use a nicer shell, fish, oilsh, rc, etc. but it's gotta provide this key Posix compatibility. The Posix Bourne shell language is pretty simple. This is not a big ask.
Not a oils maintainer, but:
I took a look at your report, and it seems like it could use a bit more detail. Things like clearer steps to reproduce, expected vs. actual behavior, and a more descriptive title might help get it addressed faster. Open-source projects often have limited resources, so anything that makes it easier for maintainers to pinpoint the issue can speed things up. Maybe updating the report with more context could help move it along?
Looking at the original posting, the maintainer knows what the bug is. The stopper is more along the lines of "This looks synthetic, so it's not high priority. If it's a priority for you, then you should fix it yourself or make an argument for its priority." followed by oguz saying "It's not actually my problem either, I'm not invested in osh.". (not actual quotes: https://github.com/oils-for-unix/oils/issues/1881#issuecomme...)
The bug is that osh leaves the script fd open for the child process when executing a command, allowing the child command to mess with the parent script. I don't see this as a huge issue for everyday interactive use, but I'd prefer my shell to not do that. If I were executing programs with limited capabilities, I'd consider this a possible vector for security bugs. That is to say, I wouldn't use osh scrpts if I cared about security.
(Blog author here) Hehe yes, Use it for a long time now! But at least in my bubble people already talk quite a bit about it, other than Oils, Radicle or Simplex :)
Browsing through the documentation for Oils, it seems to be organized in a way that's very confusing. When you open the fish shell website it was two clear buttons for Tutorial and Documentation.
[0] https://fishshell.com/
reply