So the massive drawback of fish is it's incompatible with bash (and other shells people use). If you're in fish, this is easily remedied because almost every machine has bash too. However, you can't expect another machine to have fish.
However, I just really like fish. I also live out of my own shell, and I don't spend much of my life remote-ing into other machines. When I do, my mind flips into bash just as easily as I flit from TypeScript to C#. To me, this is largely a non-issue, aside from when I need to work out how to set the `$SHELL` variable for a program that expects bash.
I think this warning is actually harmful: Years ago, I read this argument about fish and it turned me completely off using it.
Only more recently have I really realised this never applied to 99% of my (most people's?) use-cases.
The logical step many people miss is that shebangs make the compatibility of the user's shell largely irrelevant: the only real compatibility concerns are the bash version or `sh` aliasing on the user's system.
e.g. making bash scripts compatible with current macOS systems (outdated bash version and bsd-ish non-gnu binaries) is a far bigger pain than any compat issues fish brings.
> Only more recently have I really realised this never applied to 99% of my (most people's?) use-cases.
every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash.
so, i say it applies to essentially every use case where you didn't already know how to do it.
I love fish, but the fact that every answer to your questions is written in another language and has to be translated affects EVERYONE.
> every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash.
I don't get this argument: The solution is to search for:
"how do i accomplish X task in fish"
This is what I do with xonsh.
Of course, the bigger point that is being missed is that when someone opts to use a shell like fish or xonsh, they're less likely to search how to do X! The reason they picked another shell is often because it is easier to use, etc. In the case of xonsh, it's mostly just Python. I do a lot more in it than I could do in bash, because I don't need to search the Internet for anything.
I've been using Fish as my primary shell for years. The vast majority of the time those Stack Overflow answers written for Bash work as written in Fish with no changes.
Occasionally you'll need to write the command substitution or command chaining in a different way, but once you get over the initial learning curve this is easy and pretty mechanical.
Very rarely I find some command that just doesn't work in Fish, in those instances it's easy enough to open the bash shell or throw it into a script file.
> every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash.
Those answers, imo, come in 3 forms:
1. Short simple bash commands that will work in fish
2. Overly clever "one-liners" that would be better as a script
3. Edge cases.
(3) is rare enough that I don't see it as a big enough hurdle to avoid using fish.
> The logical step many people miss is that shebangs make the compatibility of the user's shell largely irrelevant: the only real compatibility concerns are the bash version or `sh` aliasing on the user's system.
It's a huge problem if you have stuff that is expected to be sourced into the shell rather than executed as a script., for example, because the sourced stuff provides a large API of functions.
In my experience, the only time I do this is with files that have been provided explicitly for my shell of choice.
The only exception to this that I see regularly is shell installers auto-adding some directory to the PATH env by making automated changes to bash/zsh confs in $HOME. This may be a slight annoyance for some, but tbh I like it as having to manually paste in a PATH addition myself allows me to audit them (and it's still quick enough).
> Biggest tip for fish switchers: set fish as your terminal's shell instead of changing your login shell.
That's an interesting idea - I will try that. This bit me recently when I used Migration Assistant to move from a Mac with Catalina to one with Big Sur; my login shell was still set to the path for fish installed via Homebrew, but none of those packages were copied over. I managed to hack around it by copying bash into that location so that I could reinstall Homebrew and fish to finish repairing things.
If you do this, you will probably also want to add `-fish` to Terminal's preference Profiles > Shell > Ask before closing (*only if there are processes...). This will prevent you from getting prompted when closing a Terminal tab with the default shell running.
To use Bash in such circumstances you just exit Fish via ^d or type exit. The bad thing about is you execute a Bash shell which uses resources. But with today's RAM even on a smartphone this wouldn't matter. The convenience and safety (to have a working default shell) is worth it.
You can use Fish on any system where Nix runs on, btw. For example, I use it on Synology's DSM.
The main advantage is that if you screw it up or an update borks the shell itself, it's easier to fix if it isn't your login shell. At one point I decided to set Elvish as my login shell, and it turned out to not function as a login shell. As in, won't start at all. Any time I logged in, it would just immediately exit, ending my session. Work doesn't allow us to have root access (annoying), so I ended up having to boot into single user mode to set my shell back. I've done a similar thing with bash and "set -e".
Being new increases the chances of doing something like that that breaks the shell. It's annoying to fix for those of us with experience, and extremely difficult to fix for those without experience. It gets even worse when you consider that some distros like Ubuntu don't set a root password, so you can't log into the root account without sudo, which requires your user to have a functional login shell. I wouldn't want a new user to paint themselves into a corner where the only way to get their desktop working again is to remember how to boot into single user mode or boot from removable media and mount their hard drive. Doubly so if their Linux desktop is their only PC; it's going to be really annoying if the only way to write removable media to boot from is the machine that's currently broken.
Hmm, fish is approaching twenty years old and supported login the whole time. But, bugs still happen I suppose. I always kept OS CDs and later flash drives around for glitches however. Have one an old one in the tin right now.
I really don’t get this argument. In my shell I don’t type scripts on the prompt.
I use fish most of the time as a shell, but I still write bash or even sh scripts, because fish is not installed on most systems. If you run a bash script from fish, it is still executed by bash (because of the shebang).
# only test if the build succeeds
./build.py && ./test.py
didn't work in fish until recently. It used to be 'and' but they recently added && for compatibility.
I think redirects and possibly pipelines work differently in fish too, although I don't remember the details. I type those on the command line frequently. I occasionally use loops as well, though when it gets big I do put it in a file.
Redirects and pipes work as you'd expect. Loop syntax is different. The difference in subshell invocation is the thing that sticks out the most: $(cmd) vs (cmd) in fish.
Piping and redirects seem to just work, command substitution is always just parentheses with no $ in front. Process substitution is not magic syntax like in sh, it's just a command that reads from stdin, writes to a temporary file, and outputs the path to that file:
#159 kind of works with the `string collect` mechanism, although it is indeed not very obvious, compared to bash:
set file_contents (cat filename | string collect -N)
I understand that this is purely anecdotal, but I'm using fish for quite a long time, I've written a lot of tooling for myself in fish, and I agree that sometimes there are some things which are annoyingly missing from fish (like this multiline variable thing), but I would not say it makes fish significantly less powerful. And these things are sometimes fixed, too.
For me, the main thing fish provides over zsh is nice defaults. oh-my-zsh can be incredibly slow, and without it zsh does take a reasonable amount of scripting & setup to make it as "nice" to use (which is why oh-my-zsh exists).
I think their "sane" scripting is more about ux for writing short disposable logic (the type you write in a terminal), rather than more detailed/advanced/structured programming that you might save to a shell script file.
Bash/zsh walk the line of being usable enoughh for typing terse quick commands (terminal syntax) while also being complex enough for writing large scripts (programming language). They end up being imperfect at both.
I agree entirely. I've tried zsh and other replacements, but I keep coming back to Fish. It's intelligent, loaded with features, and ohmyfish adds a lot.
No other machine I connect to has fish, but for my own machines, it's my top choice. Still, I write a lot of utility scripts in bash for the compatibility and it can be annoying when I copy a command and I know it won't work because it uses some unsupported syntax in fish. Every now and then, and it is rare, I switch to bash locally to run something.
> So the massive drawback of fish is it's incompatible with bash (and other shells people use).
This drawback is also its advantage, as it doesn't need to repeat all the Bourne-ish problems. (You seem to like this :-), just pointing it out for the others.)
I think people who are interested in how they use the command line will not have a problem to learn two shells, fish for the personal use and something Bourne-ish for scripts that might run on other machines, or by other users.
The Bourne shell certainly has problems, but IMHO fish should have stuck with POSIX syntax when it's "good enough" (TM). Stuff like $(code) vs (code) makes Fish feel like it just wants to be different.
Things I think are big problems:
* Needing to quote practically everything
* Needing to remember if/fi, case/esac, while/do/done, for/in/do/done, etc.
Same for me. And fish is so much nicer that I’m not willing to use a less ergonomic shell on the system I use 99% of the time for the benefit of having it act exactly like the 1% environments.
And FWIW, those 1% environments don’t look and exact exactly like my local system, where I have a nice prompt configured and there are lots of aliases and functions I use frequently. My local bash is nearly as different from my remote bash as my fish is from bash.
There is no need to change `$SHELL` :-/ you can use Bass (https://github.com/edc/bass) to execute any bash script and it will apply the environment variables to the current fish environment.
I run Fish on all my machines as well, and it's not like it's _that_ different from Bash. Maybe just for me, since I do not use either to write actual scripts. Only thing I notice on the command line is not using a dollar sign before open parens.
My biggest drawback for fish is that there is no way to concatenate several commands inside a block that I know of.
In bash, I can run the following do the following, and the only ways I found to do this in fish are using several commands or calling `bash -c` with a subcommand.
(note that this is distinct from a "subshell", which has a separate environment and typically is more confusing than helpful. In this particular case it doesn't matter)
Nit: Fish Shell is a bit redundant, as Fish stands for "Friendly Interactive Shell".
Now that's out of my system, fish is fantastic and made me realise importance of sensible defaults. I tried zsh but configuration took longer than I would have liked, and oh-my-zsh is too bloated to start instantly.
Compared to that, I have practically 0 modifications in my Fish config, apart from few aliases. I don't use fish for more than one-liners, and I never intend to. It is a very nice very fast and very lightweight way to interact with my system, which I believe was the original point of Shells in general.
It is a bit redundant, but that's not the same thing as saying it's bad or author should have eliminated this redundancy. I think of this a bit like a Checksum, which is also a redundancy... it reduces cognitive load/likelihood of error by the reader when parsing this particular acronym. Like ATM can mean both "At the moment" and "Automated Teller Machine", saying "ATM Machine" helps disambiguate (in a way) which acronym you mean. Often context is enough to do this, but as a habit/affordance to users with variable levels of familiarity with the context, I think it's a useful and good redundancy rather than a wasteful one to be eliminated.
GNU Operating System -> GNU's Not Unix Operating System
Fish Shell -> Friendly Interactive Shell Shell
One expands to include the original acronym, but doesn't duplicate the descriptive extra words. The other doesn't expand to include the original acronym, but does duplicate the descriptive extra word.
In other words, one is recursive but not redundant, the other is redundant but not recursive.
What about bash shell? Bourne Again SHell shell. That's the same thing. But i think it can be a helpful distinction between using bash shell as an interactive shell and using the bash scripting language.
Yup. I'm one of those folks who thinks that RAS syndrome is an entertaining and occasionally useful language quirk, and not at all a problem.
For example, even within a computing context, saying "Fish shell" just might help someone understand that you're talking about the Unix shell and not the cipher, and would always help someone who's not familiar with Fish to at least understand that you're talking about an alternative Unix shell.
By contrast, whenever someone posts a Hacker News article about ML, the first comment is invariably someone complaining that they thought it would be about machine learning, and this is unnecessarily confusing, and a borderline injustice, it should change its name, etc. It would probably be easier for everyone involved if it were idiomatic to say "ML language", even thought doing so would be redundant.
But ML preceded ML (at least as a somewhat widespread topic of discussion), so it's the machine learning fans who get to come up with alternative terminology.
I could not agree more, I'm sure zsh can do everything fish can and a lot more, but getting it to that stage would take me more time than I'll spend interacting with fish for the next few months
I disagree that it's actually redundant. It's like if back in 2004 somebody said "Apple computers are overpriced and underpowered." Technically, "Apple" in that sentence stands for "Apple Computer," so you're saying "Apple Computer computers are overpriced and underpowered." But that's fine, because it's just part of the company's name, not actually a redundancy. No copy editor would have flagged that, but they would have flagged attempts to remove the redundancy by saying things like "Apples" or "Apple Computers." Similarly, Fish is a name, so adding "shell" is useful in identifying the thing you're naming.
They could have written "Fish the shell" to disambiguate from "fish the animal" and nobody would have complained. But they left out "the", and now it's redundant?
It is, and "RAS syndrome" (redundant acronym syndrome syndrome) should be encouraged, not avoided.
"PIN number" is easier and faster to understand. Probably better understood than "PI number" or the expanded form. And in this case, a link just named "fish" would have been fairly ambiguous.
We like our nouns to be general, and rather turn the acronym into an adjective. It makes good sense too: PROM memory, BluRay disc, OLED display show their connections
Your first example is a recursive acronym (actually a backronym in this case), and is deliberate. That's the trope. Redundancy is usually just incorrect but common use of natural language.
Edit: I'm wrong about WINE being a backronym, but it is a recursive acronym.
I love Fish, I've found it super easy to write small helper utilites for working with virtualenvs or opening Sublime projects. The barrier to scripting is so low and the language so approachable that if I have an idea for a new function I'd like to write, I can get it working in < 10 minutes almost every time. +1 to all the comments about `abbr` for abbreviations, makes working with Git great since I can still tweak the command before if I need to before it runs, plus it helps me remember what the command actually is instead of just setting & forgetting like with an alias.
I switched all my home machines' shell to fish, and my work computer also to fish, and it has been an amazing productivity boost for myself. The extremely ergonomic way it represents history (old commands) is what does it for me.
If I need to script something, I always do it in bash (which is easy to transition to from bash). I don't use the fish language for any scripting because of incompatability, but as a command line interface to my systems it has been a massive boom to my quality of life. I could not reccomend it more.
This shouldn't be downvoted. I don't think that this person is necessarily complaining that it was reposted; rather it's sometimes nice to be able to go back and see previous discussions.
I've been using fish for about seven or so years now. I've read a lot of people complain about the POSIX incompatibilities, and while I agree that that used to be a relatively annoying issue at first, most of it is not a problem in newer versions of fish (missing && was annoying, for example).
The fact the syntax diverges from bash/zsh is IMO a great boon to fish. I've enjoyed writing fish scripts much more than zsh/bash scripts.
At work I write both for things that runs on dev machines, since I converted a lot of colleagues to fish, and writing the bash/zsh ones is usually not that much effort to write.
Sure, it's a bit of a maintenance burden in theory, but it's not become a problem in practice yet. A few times I had to wonder "how do I sensibly do this in bash/zsh" when it was pretty friction-less in fish, but it hasn't happened often.
Another thing regarding compatibility: I've never had it be a major problem when things _truly_ were incompatible, since as others in the thread mentioned, I could just do `bash`, run the script and then CTRL-C.
I’ve used Fish for years and always suspected it offered command history by directory. Fish really “just works” so I never felt the urge to investigate and verify my suspicion.
It also seems to have a type of per-command history. As you begin to type the command, you can tab through and auto-complete other similar commands you’ve done.
I'm a fish user for over 10 years now; for me a big part of the appeal of fish was (and still is) that I could get a much better quality of life without having to train myself to wizard-level with the less ergonomic but ubiquitous bash. I'm sure any black belt bash wizard will leave me in the dust on every metric, but that's fine, I don't need my shell environment to be super optimized for maximum effectiveness, it just has to be good enough to do my work and get out of my way. Fish does that very well for me.
I definitely agree with you, it's just not worth struggling with something you don't like.
For me this was vim. After struggling for many years with this ancient and difficult text editor peddled as the holy grail of productivity one day i just said fuck it and switched to a more sane text editor called nano. My life became instantly better and I've never looked back.
I really wish I made the switch earlier instead of suffering through the never ending annoyance of vim because i at the time I thought i was still learning it and one day it will all be worth it.
I'm glad that you are happy with your setup. Every one of us is so special that there could be no one size fits all solution. The reason I started going back to bash and to some extent POSIX shell is a simple question which I nowadays ask myself: do I know why I am using this? or: do I _really_ need this? When I lack a strong reason for picking up something, I drop it, and when I can live without learning a new tool, I do it.
Fish is fast but the thing which stops me from keep using it is that fish is not POSIX compliant. so I just use zsh for interactive shell and dash for scripting (and use bash when dash is not enough).
It's easy to configure zsh to be mostly like fish. Here is my zsh setup, I don't use any zsh framework, just install them with my package manager and source related plugins in $HOME/.zshrc.local (except powerlevel10k which I need to clone the repo and source powerlevel10k.zsh-theme)
Favorite feature of Fish shell is `abbr` abbreviate. Which expands the abbreviations after <enter> or <space> allowing it to reveal the magic behind it, for screensharing/observability and for modification. I use it with --long-options too so the abbreviations are more self-documenting.
> once it's loaded with all the plugins that make it behave like default fish
Fish also feels more cohesive in this situation; a case of built-in features being more refined due to being under the purview of maintainers and shipped to everyone.
I switched to fish in the last ~6mo, after bash for years. I feel like its made me more productive, especially the auto complete.
I have read a number of opinions concerned about the portability of fish. Perhaps, my own use case is different, but I have experienced very few compatibility problems.
The most common compatibility problem for me is copy pasting a shell command with `$(...)` in it. Switching to bash and re-pasting is pretty effortless, but this doesn't happen often.
Unrelated but the logo reminded me of some Internet culture. Way back in the AOL days where phishing was coined, hackers referred to phished accounts as <><. The little programs that spammed "I'm from AOL what is your password?" messages were called phishers or baiters and the programs that held hacked accounts and their password, or <><, were called phish tanks.
The problem with these alternative shells (to me) is that you'll have to install the shell on other machines before you can use the script you wrote. Bash being present on just about all Linux distros makes it useful, even if the scripting is quite terrible. And if I'll have to do something more complicated I'll use a proper scripting language like Python instead of learning another shell language.
It would be great if bash was a little less crap though.
I think my biggest annoyance using fish daily for years is with certain string subcommands just barely not having enough power to replace sed/grep/awk usage in bash scripts but that's been improving.
I find it so much easier to quickly throw together a function or a script for whatever random task I want to do in fish than in bash and actually have confidence that it'll work without tons of trial and error and needing to look up syntax.
I always wondered why anyone would do this. IMHO modality and shells just don't get along well. Besides that, readline-like bindings are both good enough and you're likely to encounter them in the wild when working with ssh, database prompts, and so on.
Yep, what kind of issues you had? Works well for me.
Not sure what do you mean by efficiently -- but my tip is pressing alt-e to edit the command in external editor when it's multiline (although it's not limited to vi mode in fish)
It interacts pretty poorly with, e.g., terminals in IDEs, but is essential for my day to day in my regular terminal emulator. Worth noting I'm not a vim power user, but I could live without vim keybindings for moving around, it just feels more naturally.
I have tried vim mode in fish and I didn't like it. I find I don't really need vim bindings in the shell because I'm almost never editing. Alt+e to open the current command line in my editor works really well for me when I do want vim.
I really like fish shell. After ditching bash and picking up ksh for its much nicer array notation, I needed a frontend shell, and it really fits the bill. Its defaults are really friendly, and it is very configurable.
However, I just really like fish. I also live out of my own shell, and I don't spend much of my life remote-ing into other machines. When I do, my mind flips into bash just as easily as I flit from TypeScript to C#. To me, this is largely a non-issue, aside from when I need to work out how to set the `$SHELL` variable for a program that expects bash.