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.
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).
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.
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.
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.
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?
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.
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.
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.
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.
[+] [-] ddek|4 years ago|reply
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.
[+] [-] lucideer|4 years ago|reply
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.
[+] [-] mattgreenrocks|4 years ago|reply
Biggest tip for fish switchers: set fish as your terminal's shell instead of changing your login shell.
[+] [-] andix|4 years ago|reply
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).
[+] [-] xvolter|4 years ago|reply
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.
[+] [-] hibbelig|4 years ago|reply
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.
[+] [-] kstrauser|4 years ago|reply
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.
[+] [-] flying_sheep|4 years ago|reply
[+] [-] pkulak|4 years ago|reply
[+] [-] mixmastamyk|4 years ago|reply
1) Use fish interactively, with quite a few aliases.
2) Write <= 10 line scripts in sh, perhaps with a bashism if it is very helpful, and only run on my machine.
3) Write > 10 line scripts in Python.
[+] [-] knodi|4 years ago|reply
[+] [-] mxcrossr|4 years ago|reply
I can, because whenever I get access to a new machine I download and compile it!
[+] [-] Bancakes|4 years ago|reply
[+] [-] mFixman|4 years ago|reply
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.
```
(cat file_1; cat file_2 | grep something) | sort
```
[+] [-] e3bc54b2|4 years ago|reply
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.
Either way, glad to see it on frontpage.
[+] [-] bglusman|4 years ago|reply
[+] [-] yewenjie|4 years ago|reply
[+] [-] t3chguy|4 years ago|reply
[+] [-] luke2m|4 years ago|reply
[+] [-] chc|4 years ago|reply
[+] [-] hibbelig|4 years ago|reply
Isn't it funny how the mind works?
[+] [-] s_dev|4 years ago|reply
Isn't this a common trope with software e.g. "WINE is not an emulator" or people saying "ATM Machine".
[+] [-] dec0dedab0de|4 years ago|reply
[+] [-] spacefiish|4 years ago|reply
[+] [-] cuddlybacon|4 years ago|reply
I wrote so many more small scripts for myself. Since I didn't need to consult a syntax manual every, the friction was low.
[+] [-] hak8or|4 years ago|reply
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.
[+] [-] dividedbyzero|4 years ago|reply
Did you mean dash?
[+] [-] onebike|4 years ago|reply
[+] [-] claytonjy|4 years ago|reply
[+] [-] tartoran|4 years ago|reply
[+] [-] WalterGR|4 years ago|reply
[+] [-] spoiler|4 years ago|reply
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.
[+] [-] khaledh|4 years ago|reply
- jorgebucaran/fisher (plugin manager)
- IlanCosman/tide (prompt)
- jhillyerd/plugin-git (git abbreviations)
- PatrickF1/fzf.fish (history finder, and other autocompletion)
- jethrokuan/z (directory jumping)
- jorgebucaran/autopair.fish (auto-complete quotes)
The auto-complete experience is what I like most about Fish, followed by abbreviations (not aliases) auto-expansion.
[+] [-] nofunsir|4 years ago|reply
Fish + oh-my-fish + theme-bobthefish + powerline modified fonts
One of Fish’s features I like the most is a per-directory command history stack, on top of the normal history stack.
[+] [-] divbzero|4 years ago|reply
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.
[+] [-] mehdix|4 years ago|reply
[+] [-] dividedbyzero|4 years ago|reply
[+] [-] dashezup|4 years ago|reply
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)
- grml-zsh-config[1]. lots of useful base stuff
- zsh-completions
- zsh-autosuggestions. fish-like autosuggestions
- zsh-syntax-highlighting. syntax colors
- fzf-key-bindings.zsh / skim-key-bindbings.zsh. fuzzy file/history search
- powerlevel10k. fancy prompt
[1] https://grml.org/zsh/
[+] [-] ElijahLynn|4 years ago|reply
e.g. `abbr --add --universal -- gg 'git log --graph --oneline --all'`
[+] [-] gfiorav|4 years ago|reply
I really enjoy it. Faster than zsh once it's loaded with all the plugins that make it behave like default fish.
[+] [-] mattgreenrocks|4 years ago|reply
Definitely, and it's noticeable.
> 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.
[+] [-] cies|4 years ago|reply
If those little copy-paste sh/bash scripts would have worked, I'd still be on Fish.
[+] [-] lbhdc|4 years ago|reply
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.
[+] [-] notadev|4 years ago|reply
[+] [-] alberth|4 years ago|reply
I had a good laugh when I read the title of the website praising to be modern 31 years ago.
[+] [-] FriedrichN|4 years ago|reply
It would be great if bash was a little less crap though.
[+] [-] danmur|4 years ago|reply
[+] [-] iamevn|4 years ago|reply
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.
[+] [-] cassepipe|4 years ago|reply
Last time I tried I had not such a good time. Would love to see a tutorial on how to use it efficiently.