They did it also because with the old syntax it was unintuitive how to put commands inside quotes. It borrowed the new syntax from bash but it wasn't ONLY to be more bash compatible. It solved a real fish shell problem also.
They've been doing these small improvements to support more standard syntax for a while and I approve. (e.g. 3.0 added &&/|| as aliases for and/or, 3.1 added &> redirection syntax, and "X=Y foo" for setting variables for one command)
I've been using fish for 2 years now and I pretty much live in the terminal. I would feel handicapped without it.
Just use fish and use shebangs `#!/bin/sh` (which should be in your scripts anyways) and you can keep writing/running POSIX scripts all day. I think it's the best option until nushell[0] is ready.
As an added bonus now that you don't use bash interactively you can substitute dash[1] and increase the speed of most POSIX scripts, win-win.
I'd also recommend zoxide[2], i feel like it's one more must have no matter what you do in the shell.
Fish is so great! I'm a user for 7 years. The autocomplete suggestions are so helpful!
However, since using Github Copilot I'm expecting a bit smarter suggestions. I wonder if anyone has tried putting a GPT-3 like engine behind command line autocomplete suggestions. Or maybe the Copilot team offer a sort of API for this.
I remember that I was able to replicate this last year, not 100% sure why I'm not using it daily tho. :D
One thing to note, the limited waitinglist he talks about in the video is done, and now you can sign up and "pay" for ~NLP~...ahem CLP tokens as OpenAI calls them
Switched and never came back. Always recommend people to use fish if they're not the "customize everything everywhere to my liking" type.
The defaults of fish are great and common tasks are simple. The for loop syntax was so intuitive I got it right the first time without checking Google (which I have to do every time I write a bash for loop).
> Always recommend people to use fish if they're not the "customize everything everywhere to my liking" type.
Fully agree. It feels like fish is the Apple of shells, in that regard. Unless you really love to tinker with your shell, the great defaults and great UX make it really easy to recommend.
I find myself customizing fish way more than I ever did with Bash. Writing custom completions is easy and I find the scripting syntax a lot nicer. Combining the two is really powerful. Granted, fish ships with a ton of completions out of the box so you may not need to write your own.
It's not difficult to customize. IMO, it's actually easier to customize yourself than bash/zsh because I find the fish syntax much more natural than bash, but YMMV.
That said, I believe that zsh has a bigger community, and therefore most likely a richer ecosystem with more plugins. For example, oh-my-zsh has 142k stars, and oh-my-fish has 8k stars.
However, even with the rich ecosystem of plugins, I wasn't able to get my zsh to be as pleasant to use as my fish, where I only have some self-made customizations (not even using oh-my-fish).
But if having lots of plugins to choose from is important to you, zsh may be a better choice.
I'm a previous bash user who now uses fish and loves to customize everything, and compared to bash, customizing fish is a joy. Its so much easier to do, using oh-my-fish brings a great selection of plugins (admittedly lots of them are inspired or clones of oh-my-zsh plugins) and writing plugins is a breeze as well.
Switched and came back after about 3 years (to zsh).
Fish is nice in many ways, but it kinda lives up to its "A command line for the 90's" slogan. It's better than what came before it, but I'm not sure it's better enough. Using a non-POSIX shell can feel like death by 1000 cuts sometimes, and I wasn't sure the benefits of Fish were worth the cost. Also, scripting feels like a bit of an afterthought in Fish and that's a very important part of a shell to me.
These days I'm feeling optimistic about Nushell; it's not quite ready for most people to use as a daily driver, but it's getting there and it has a much stronger value proposition than Fish.
I’m a long term bash user, I tried fish and just couldn’t get used to it (death by 1000 cuts is a great way to put it.) I’ve recently settled on zsh but I still prefer bash’s basic history (e.g. just pressing up without typing any command)
By default it’s iffy. I’m sure you can configure it to match bash but if I open a shell, spawn a service (e.g. run a typescript backend,) do some work in another terminal and come back the command I get when just pressing up is different. It’s such a small thing that I’ve stuck with zsh regardless, and command completion is worth so much more to me, but I still consider it a nice to have to figure out one day.
My other was similar: bash, zsh, fish, back to zsh. The ecosystem around zsh is just so much more robust. Fish is better out of the box than zsh, but once you start customizing fish loses its shine.
I tried bash first, with every bell and whistle added. I tried all the scripts and tuned my .bashrc and .bash_profile and PS1 and all the crap. It was a huge chore.
Then I tried switching to zsh with oh-my-zsh and all that. 42 million tunable bits and I still didn't get it to my liking.
Then I found Fish and 95% of the stuff was good enough out of the box. The only things I've really added was Starship[0] as a prompt - again good enough with pretty much zero configuration and fzf[1] for history search.
Now I use it everywhere, synced via Homeshick[2]
I still use bash to write shell scripts that aren't long enough to be converted to Python though.
I switched to fish about 7 years ago and never looked back. It feels so much more natural to use than bash. With all the hype (and better ecosystem) of zsh, I once genuinely tried using zsh, but eventually came crawling back to fish.
Using just plain bash seems so foreign to me. Having no FZF command history search or intelligent auto-completion would kill my productivity. I'd say it's as essential to my workflow as tmux.
The only major downside of fish, in my experience, is the incompatibility with bash scripts. Sometimes it's a hassle to rewrite those to be fish-compliant. But honestly, this is something I run into once in a blue moon. On the flip side, the simple fish syntax really encourages me to write my own fish functions, whereas with bash I was always dreading writing bash scripts.
Personally, I can fully recommend fish. In my experience, switching to it is not even painful at all, not like vim which took me quite some dedication to get through the learning curve (switched from Sublime Text).
~30 year bash/sh user here (glossing over the regrettable, mercifully brief dalliances with csh and ksh). I can’t claim to be long suffering, because I (still) enjoy using bash.
In December just gone I gave up on macOS after 17 years and switched to Linux. Thought I’d take the opportunity to try a new shell and went for fish (though I still use bash on certain remote hosts for a variety of reasons).
autocomplete and colours/highlighting are more than enough to keep me using it. I really enjoy them. But…
I don’t yet love how history works. Four months in, I still can’t get used to not having ctrl-r.
I miss the symmetry of `do … done` in loop syntax, finding `for … end` jarring.
The lack of !! really grates sometimes. I was going to say I miss `^x^y` last command modification, but actually I can’t recall trying it since switching.
`VAR=x cmd …` doesn’t seem to work quite how I expect. I have an alias/function to perform SSO login to AWS, which expands to `BROWSER=otherfunc aws sso login` - otherfunc itself expanding to `firefox -P workprofile`. This stubbornly opens a Firefox tab in some random window, regardless of profile - despite otherfunc on its own always working. I did not, IIRC, have this trouble with bash.
> I don’t yet love how history works. Four months in, I still can’t get used to not having ctrl-r.
I think it's worth getting used to but there are plugins like fzf that implement ctrl-r
> `BROWSER=otherfunc aws sso login`
Aliases/functions are generally not visible in child processes.
I guess it worked if the "aws" tool invoked BROWSER via a bash process that either sources aliases from a bashrc, or reads exported functions ("export -f otherfunc").
It would work for fish too if "aws" invoked BROWSER via fish (though fish doesn't need exporting, since functions are also loaded in non-interactive shells).
I recommend that you make otherfunc a script, then it will work everywhere (also with arbitrary wrappers like strace, gdb).
Just try it for a couple weeks. I bet you won't go back to bash except for writing bash scripts for work :) . Even the defaults without changing anything are so awesome. I always ad a simple theme "ays" and "fzf" and not much else. I like to keep it simple, but fish has so many built ins it's awesome. Honestly I don't use it for scripting though just CLI, the only scripting I do is to support CLI capabilities. I do use the ubuntu PPA though, the ubuntu 20.04 default version of fish is quite old.
I have used fish for so many years I have lost track. Maybe 10 years. Occasionally I need bash and then I just launch a bash shell. But I have gotten fish to work with pretty much everything I need without problems whether prompts or Python environments.
Fish excels as an everyday interactive shell. I never program shell scripts. I write Julia code whenever something equivalent of a shell script is needed. Before that I often used Go.
I've been using Fish for years and spend my entire day working with Python. Python's virtualenv has an `activate.fish` command, I've never had any problems with it. Additionally, we have a ton of internal tooling built in a fabfile, so I've written a couple of snippets of fish that automatically activate that .venv (Poetry managed) whenever I cd into a directory that has one, and also expands a bunch of env vars into the shell session. I've also got this feature request in on the virtualenv repo in the hope that one day we can have activate.fish emit an event - https://github.com/pypa/virtualenv/issues/1456
Just loving every single bit of it since I switched to it. Had a couple of thoughts of migrating to zsh mostly because its more POSIX compliant but it doesn't look like such a valid argument as time passes by
I think POSIX compliance of interactive shells is completely irrelevant. POSIX shells are relevant when you're writing scripts that will be distributed, but there's no reason that needs to be done with the same shell you use interactively. I use fish presently and zsh before that for nearly 15 years, but my shell scripts have always started with #!/bin/sh
It's not like fish installs to /bin/sh, nor are /bin/sh scripts executed using fish just because your interactive shell is fish. I guess these are the two misconceptions the common worries are based on?
Same. I've been using fish forever. Scripts that use sh or bash still work fine.
The fish scripting language is much easier to read and write than bash (for someone that doesn't write many scripts). So for local scripts I use it but for anything shared it's still bash scripts.
Yeah I agree POSIX compliance is irrelevant in the interactive usage context, the only issue that rose here and there were command substitutions mostly, something which this release takes care of.
The sole reason I was contemplating switching to zsh in regards to POSIX was the fact my shell scripting knowledge is rather shallow and I could perhaps improve it a bit while working on functions I write for personal interactive use.. Needless to say I've written them in fish haha.. If my assumptions are right what I need to master is combining properly the coreutils and the general mentality of piping things from one command to another etc - I could be wrong tho
Same here, totally don’t get the whole compatibility argument. If I need to script anything of any complexity I use a more proper programming language anyway such as Python, Ruby, Julia or maybe even Go as it makes distributing apps/scripts real easy.
I made the mistake last year of falling in love with xs-shell https://github.com/TieDyedDevil/XS, talking to its maintainer (who recently put xs out to pasture, as it were) who is now moving all his stuff to es-shell, switching my romance to es-shell https://wryun.github.io/es-shell/, merging in 2 forks of it to my own version https://github.com/pmarreck/es-shell/ aaaand having a kid and basically running out of time.
This shell makes a ton more sense to my brain than the usual bash/zsh/fish rigmarole, it just needs some love. It's older, but basically much smarter.
The last thing I was working on was a way to capture all of stdout, stderr and return code from a single run of a command, for testing purposes, because the OTHER thing es-shell desperately needs is a proper test suite, and being able to assert on all/any of those side-effects (and the return value) is IMHO fundamental to a proper suite. I figured one out for bash https://github.com/pmarreck/tinytestlib but not one for es yet.
I used OhMyZsh for years with the Agnoster power line theme and over the years it got slower and slower. Tried Fish about 6 years ago and immediately spent the rest of the day tweaking an Agnoster theme to my liking because everything about it was better than Zsh and waaaay faster. My fork is here [0] for anyone interested, though the readme and screenshots are from the original.
I’d say that’s more a OhMyZsh problem than a ZSH problem. There’s definitely faster and better frameworks/plugin managers.
However the crux of the issue is that a bunch of the neat features are built into default Fish vs being behind plugins in ZSH.
I still think (with sufficient effort), ZSH is the best (and I think configurable to be faster than default Fish with equivalent features), but Fish is the best out of the box experience.
I've just taken Fish for a test drive and I'm really impressed. I use the Starship prompt in Zsh and it worked out of the box in Fish. It appears direnv will too (which I rely on).
The one thing I can't work out is how to change the cursor to a block, it's a line. No vi-mode or anything, just a nice rectangle. I tried `set fish_cursor_default block` to no avail.
Does anyone know how to disable the bright red color when you first start typing a word? I find it very distracting (specially on over-saturated wide gamut displays) and went back to zsh because of it.
Is that perhaps the syntax highlighting telling you that you haven't typed a valid command yet? I haven't used fish (I use zsh), but that's my guess. So, I guess try disabling syntax highlighting or changing colors related to it.
I love fish. It helped me get into linux terminal. It really accelerates the learning curve and turbocharges explorability. I wish more TUI types of apps took hints from fish’s UX
I used fish for a few years and finally switched to zsh. I wouldn't consider myself a super shell power user, so eventually I got tired of trying to make standard things work (such as nvm and similar helper utilities). Yes there are workarounds and solutions but I just wanted plug and play for stuff I'd find in the wild. Turns out that zsh with ohmyzsh has much of fish's functionality (that I utilized anyway), so I'm happy with it.
I can be believe it’s faster than a poorly configured zsh (which unfortunately is quite common), but would be curious to see actual test results, with things like “input lag”, “time to first prompt”, “command lag”, etc. like is measured with the excellent zsh-bench (https://github.com/romkatv/zsh-bench#what-it-measures)
I've never tried zsh. I remember reading in the interwebz that if you go towards feature-parity with fish in a zsh setup, the latencies here and there, adds up and makes it slower than fish.
Here is a relevant blog post:
https://carlosbecker.com/posts/fish/
That's pretty big news for a more POSIX-like behaviour!