Hacker News Reader

Comment by dangus | Hacker News Reader

Beat me to it. A lot of the value in choosing a specific shell lies in its popularity, so I think you really need to have a specific reason to choose something outside of bash/zsh/fish.

View on HN

> you really need to have a specific reason to choose something outside of bash/zsh/fish

The reason in question is that not that long ago, people said "you really need to have a specific reason to choose something outside of bash", and people choosing to go off the beaten path lead to zsh and fish becoming powerful and way more popular/well-supported than they were before.

Being adventurous can be part of your reason.

"Popularity" probably has more to do with Apple moving to Zsh than anything else. Zsh has been more powerful than Bash for literally the entirety of the existence of both. It surely was back in like 1993 when I first looked at them. The "emacs of shells" might not be the worst summary.

Fish is a more recent addition, but I hate its `for loop` syntax, seemingly copied from BSD C Shell, which this Ion shell seems to have copied (or maybe Matlab or Julia?). Baffles me to impose a need for `end` statements in 2025. In Zsh, for a simple single command, I need only say `for i in *;echo $i` - about as concise as Python or Nim. In the minimalism aesthetic, Plan 9 rc was nicer even before POSIX even really got going (technically POSIX was the year before Plan 9 rc) for quoting rules if nothing else.

I think it's more insightful to introspect the origins of the "choosing something outside bash" rule you mentioned. I think that comes from generic "stick to POSIX" minimalism where Bash was just the most commonly installed attempt to do only (mostly) POSIX shell.. maybe with a dash of "crotchety sysadmins not wanting to install new shells for users".

Speaking of, the dash shell has been the default on Debian for a long while. So, I think really the rule has always been something "outside POSIX shell", and its origins are simply portability and all those bashisms are still kind of a PITA.

> "Popularity" probably has more to do with Apple moving to Zsh than anything else. Zsh has been more powerful than Bash for literally the entirety of the existence of both. It surely was back in like 1993 when I first looked at them. The "emacs of shells" might not be the worst summary.

It's my impression that Apple switched to zsh because it's permissively licensed, so they could replace the now-ancient last version of bash to use GPLv2 (instead of v3). Obviously it helped that they could replace it with something even more feature-rich, but I expect they would have taken the exact same functionality under a more permissive license.

I recommended fish to some my younger coworkers recently only for somebody very senior to point out that they will be very confused copy-pasting commands meant for bash from the internet and them not working. He is right, I will hold off recommending fish. You have to know you are very ready for a new shell.

About the only common case for single line commands is that fish uses (cmd) instead of $(cmd) for subshells. Anything longer than that you should probably be pasting it into a file and executing that.

Replying to myself: I don’t get the downvotes here. One-liner Bash commands I stumble across almost always work as-is in Fish. A while back they added support for

  FOO=bar cmd

to run cmd with the env var FOO set to bar, and that was the single biggest incompatibility I routinely stumbled across. Most commands you find in random docs tend to be that simple, and most work just as if you’d run them under Bash. But if it’s a large, complex command with if statements and for loops, etc., you’re better off pasting it into a file, then tweaking it to run under Fish or just running it directly via Bash.

Someone should tell the very senior dev that nothing stops you from running “bash” if you need to paste scripts.

Minor errors stop juniors and people not used to the shell - they have no idea why something failed or really want to bother looking into it.

Mmm, I don’t love this advice.

I think the error messages fish gives out in these cases (usually related to quotations) explain the problem pretty well.

I would probably recommend it like this: “I like using fish as my shell, if you want to try it out make sure you read the tutorial and generally understand that it’s not designed to be 100% bash/zsh compatible.”

I picked up fish as a junior level engineer as well, it wasn’t very hard to adapt.

I think that osh is valuable precisely because of that, since it's bash compatible. The project also has ysh which is not bash compatible, but fixes a lot of shell brokeness, including the #1 source of shell bugs, the need to quote almost 99% of variables and subshell invocations (and not quote them in the rare case you actually want splatting)

https://oils.pub/osh.html

https://oils.pub/ysh.html

I feel like there's a pretty big difference between recommending Zsh and a shell without compatible syntax. The latter assumes you'll spend so much time running ad hoc complex commands in your shell, without opting for a proper scripting language instead, that you'll offset the pains of translating any existing commands to the new shell syntax.

Fish is great. NuShell is amazing. But once I start doing such data pipelining, I'd much rather open a Jupyter notebook.

I don't know if this applies to RedoxOS users.

As for why you might use it on Linux, it seems like it's meant to be "friendly" like Fish, but with more emphasis on scripting rather than on interactive use. It looks like a very comfortable scripting language. Something that visually resembles Lua but also has all of the familiar shell constructs would be an excellent scripting language IMO. And that's what this seems to be.

So they should say that.

Reply on news.ycombinator.com