Wow, very surprised how quickly they got this done. Looks like it took about a year, total, for the rewrite? Speaks well of their choice to use the Ship of Theseus strategy to port individual parts from C++ to rust, rather than giving into the temptation to do a "full" re-write.
A fish user for the last few years here.
Fish is all about contextual autocomplete and zero configuration. It just works out of the box. It suggests completions as you type and the experience is very smooth.
Unfortunately the scripting language isn’t sh-compatible but it’s fine as you can still run scripts in bash.
Frankly I use python and PowerShell (to control Windows boxes) for scripting 99% of the time and a quick `#!/usr/bin/env bash` shebang on top is how I learned how to bash script anyway since Debian was/still uses Dash for /bin/sh
Fish really is what it says on the tin: Friendly Interactive Shell. Easily get 90% of the benefits of zsh with just a install and chsh.
It has a lot of sensible defaults out of the box, and the scripting language is less esoteric than bash. I'd go into more detail but it has honestly been nearly a decade since I switched, so I barely remember. From what I recall, you can setup bash or zsh to do most of the same things, but that requires addons or tweaking configurations. With fish you just get a sensible shell right out of the box.
Writing fish completions is really easy, too. I never bothered when I used Bash, but I write them for various utilities in Fish and it makes the shell more pleasant to use. Several of my custom ones have been supplanted by upstream completions having been added in a subsequent releases.
How is history recording in fish? I found that keeping an eternal history tagged with screen session ids is a huge productivity boost in my bash setup and hoping to see if it's feasible in other shells.
I set a unique session ID in screen sessions, which get recorded in history, which lets me resume the session history streams across reboots/screen restarts.
> explain what Fish does differently to zsh or bash
Fish adds a bunch of features that, when you think about it, should have been standard a long time ago… like creating auto-completions from man pages, syntax highlighting on the command line and 24-bit color out of the box. Little things like providing autocompletion of targets if you happen to be in a directory with a Makefile and autocompletion for apt, rpm and yum package managers.
macOS users: Fish can autocomplete brew [0] commands and packages too. Super handy.
As I often see on HN, yes, you can plugin and script your way to adding these features to Bash and Zsh; the beauty of Fish is you get all of this out of the box without having to configure anything. Bash and Zsh plugins require another layer of management and (often) slow things down.
It's one of the first things I install on a new Mac and have made it the default on my FreeBSD machines as well.
Developer Brett Terpstra has a blog post series [1] about going from Bash to Fish; reading this helped me take the plunge. If you're a Bash enthusiast as Brett is/was, make sure to read his first article "Branching out from Bash: Fishing expedition" [2].
I was able to adopt fish shell and get many features from bash that were provided from plugins. I prefer the more “stock” shell configuration for easier maintenance across computers and over time, and a less complex dotfiles project. https://github.com/andyatkinson/dotfiles
On a team I limit my fish shell use to my own machine though, and would use bash for scripts to share with a shebang line. I also switch to a bash shell when needed.
I used to have an elaborate zsh config but I got tired of maintaining it so I switched to fish. Fish has the most "modern" default configuration of any shell I've seen, so with fish I'm satisfied without needing to maintain configuration.
The big thing for me was the intuitive auto-completion which I hadn't seen anywhere else at the time, but this is now also available in zsh via this plugin:
Fish more or less just works. It has a lot of sensible defaults out of the box, and you can be extremely productive with it right off the bat.
It also forgoes compliance with POSIX intentionally, with the rationale that POSIX can sometimes be an obstacle. So you get things that are dramatically better than how they work in other shells, like the prompts. Instead of injecting stuff into envars, you just make a function that echos your prompt out. Same goes for right prompt and most of the other configuration stuff; its all function driven
TLDR: Fish throws out old stuff (sh compatibility, mostly) in order to be very user friendly (at least to users who aren't used to sh), and is very good at doing so.
(Written as a user who is very accustomed to sh and gave up after trying fish briefly)
As a counterpoint, after 15 years of being proficient in bash, the second I tried fish I never looked back.
There are a few minor differences in scripting that I had to figure out when I ran into them (while/if syntax, process substitution, some other minor things), but these were small enough that it didn’t matter.
I’ve had multiple coworkers with a similar experience.
I switched to fish a few years ago as well. Great productivity boost for very little fuss.
I still write my scripts in bash, though. I feel it’s counterproductive to expect the script user to download fish when bash is already preinstalled nearly everywhere. If someday fish reaches similar penetration I’ll reconsider.
To be clear, I intended my comment to either be neutral or an endorsement of fish. I found it too painful to bother with, but I'm unusually attached to sh.
Do note some shell scripts won't work by pasting as is. You might need to put it through sh or bash interpreter instead.
fish is good for a shell but for scripting, probably better to stick to bash for portability. People tend to treat both the same.
On the other hand, most if not all of fish capability can be accomplished via zsh plugins while retaining shell script portability to a decent extent to bash.
> On the other hand, most if not all of fish capability can be accomplished via zsh plugins while retaining shell script portability to a decent extent to bash.
…if you don’t mind wasting your time on reinventing the wheel, that is. You get a lot of added benefit, for free, by using Fish. For that cases where you need to follow instructions in bash, just drop into a bash session.
Both zsh and fish offer the same kinds of improvements over bash. The headline feature of these two is the auto completion user experience. They complete as you type, with fish for example showing suggestions in a muted colour ahead of your cursor which you can complete word by word or accept completely.
zsh is a much older project and carries with it a lot of baggage in terms of configuration. fish was designed later and straight out of the box.
Intelligent auto complete is extremely useful if you are constrained with your input either by disability or by using a suboptimal device. Switching to fish really helped for ssh-ing to hosts from my iPhone.
> Intelligent auto complete is extremely useful if you are constrained with your input either by disability or by using a suboptimal device.
Well, assuming you’re a hyper-intelligent being with eidetic memory, that is. The main value of the intelligent completions isn’t conserving keystrokes, but discoverability of input options. It’s the same story for IntelliSense in IDEs.
The best way to understand is probably to try it. I feel lost whenever I‘m outside a Fish shell. Other shells don’t provide as much immediate feedback. I never use it for scripting though. Fish script language is about as unintuitive as Bash, so I rather stick to Bash.
I do find the history pager stuff interesting, but ultimately not of tremendous use for me. I rebound all my history search stuff to use fzf[1] (via a fish plugin for such[2]), and so haven't been aware of the issues
I've used Fish for a while (my dotfiles tell me I've been using it for 8 years now... how the time flies! [0]) and decided to give Nu a try.
The main problem with Nu is that it can't really be used as a full-time shell because it doesn't support job control, so a lot of nodejs-based CLIs I need for my job seem to lock up the shell. I got around it by using pueue (a daemon that manages processes), but it's clunky to say the least.
I do think it'll get better as it matures, but I've been through all that pain with Fish and I'm not sure I want to put myself through that again.
I recently gave a shot to nu + zellij (as a replacement for bash + tmux) recently and had to bail within days due to it breaking my "background the editor in this pane" habit that is pure muscle memory by now.
Here's my experience of spending a part of a day with each:
Fish:
- customizing or debugging Fish's completion was utter torture; the defaults are horrible like "carTAB" completes to "blkdiscard" when I don't have cargo in PATH
- nothing in Fish seems to have a useful `--help`, no useful summaries & quick refreshers, just punt the user to a big verbose man page
Nushell:
- no job control, no background jobs
- error handling is utterly broken
- control-C breaks unexpected things, what gets aborted seems up to luck (e.g. aborts the prompt building)
- globs inside quotes, `ls "*"`
- lots of weird parsing errors & bad edge case behavior
I'm still on bash. I was really hopeful on nushell until I discovered the error handling & control-C -- before those I thought it was "just" lack of job control, now I'm less enthusiastic about the quality.
Looks like I'll be staying on Bash! It somewhat amuses me that we don't seem to have done better than it in all these years—but I also take a lot of comfort in that. With that said, it still gets updates! So, it can and is still improved. :- )
I didn't realize how much this bothered me, but I got unreasonably happy reading that just now, so there was clearly something there.
Little QoL improvements like this are the hallmark of a healthy project.