I used fish for a while, but couldn’t get over the lack of POSIX compatibility. Lots of stuff executes shell scripts with $SHELL. This means, when $SHELL changes, you either have to rewrite all those scripts into fish syntax, or configure the services individually to use /bin/sh instead of $SHELL to execute scripts.
Couldn’t you export SHELL=/bin/sh as part of the fish startup script? There may be some trickery to make sure that interactive shells aren’t spawned with /bin/sh, but it seems possible in principle.
I don’t know. I just concluded that the system heavily assumes you’re using a POSIX compatible shell, saw close to no advantage to use a non-compliant shell (my collection of shell scripts will stay with she or bash, I don’t want to rewrite them all or lock myself in to fish) and I already know the posix shell syntax, and switched back to zsh.
EDIT: I now remember what in particular was breaking. I’m using sxhkd (simple X hotkey daemon) which lets you run commands when you press hotkeys. It interprets the command with $SHELL by default, and thus a lot of my hotkeys subtly broke in unexpected ways.
Even in interactive use I kept tripping up on lack of POSIX compatibility. Unfortunately I have too much muscle memory and still occasionally use bash/zsh when ssh’d in to servers in order to switch. I wish they’d consider an off-by-default env var to support POSIX syntax, but I understand it greatly complicates things.
I just see this as a parsing problem, not an architecture one, where POSIX-compatible syntax is merely a skin atop the niceties of the fish shell.
It isn’t mandated that your $SHELL be POSIX-compatible, but POSIX “utilities” are allowed to “behave differently” if it isn’t:
SHELL
This variable shall represent a pathname of the user’s preferred command language interpreter. If this interpreter does not conform to the Shell Command Language in the Shell and Utilities volume of IEEE Std 1003.1-2001, Chapter 2, Shell Command Language, utilities may behave differently from those described in IEEE Std 1003.1-2001.
That’s fairly vague, but seems to leave open the possibility that you can have a POSIX-conformant operating system where the included utilities are allowed to depend on $SHELL being POSIX-compatible, and might behave badly if it isn’t. In practice I would be surprised if any modern Unixes do this. It’s considered good practice to explicitly specify /bin/sh when you want to execute a POSIX shell script, especially if you’re an OS-level utility.
fizsh is another good choice. It takes heavy influence from fish while retaining a POSIX-compatible syntax, something that a lot of people in the comments here seem to miss.
I love fish, I used it for a long time and still recommend it constantly. I use zsh now because my job is heavy on bash scripting, and I found myself running bash inside fish more and more often to get access to those scripting primitives. For anyone else who needs bash, but loves fish, I recommend zsh-autosuggestions, zsh-history-substring-search, and zsh-syntax-highlighting.
I tried fish shell for some time and really wanted to like it. In the end, I went back to (my tweaked out) zsh for several reasons:
while fish’s defaults are much nicer than zsh’s, I still needed to configure a lot of things to my liking
autocompletion doesn’t work for functions/aliases, e. g., I have gl as a function/alias for git pull, and then fish cannot autocomplete, abbreviations work, but I that irritates me
history search doesn’t work as I expect, if I type the beginning of a command I have typed before, fish lets me autocomplete it (ctrl f), but skips it when pressing arrow up (I have patched that behavior out, but having to install my own fork on every new computer I use is too tedious for me)
I still recommend fish to people who don’t use the shell much anyway, and have a much better experience with default fish than default bash or zsh.
I’ve been using fish for a couple of years now and I love it not only because of its batteries-included nature (I have a few custom functions I wrote, but otherwise I’ve been basically running vanilla fish from the beginning), but also because of how damn fast it is while providing all of these great features out of the box. For bash utility compat. there’s bass but I’ve never really had to use it. virtualfish is a fantastic replacement for virtualenvwrapper.
I used fish for a little bit, but found the effect of accidentally using the wrong syntax when on a random server to be pretty frustrating. I was actually typing more characters for for-loops on average than bash/zsh, due to not remembering what machine I was on. For me, the blissful ignorance of a less-elegant standard comes out a bit ahead. The up arrow for recall is also harder for me to hit than C-r, which I can hit with a 1-key-distance tap, as I map capslock to Ctrl, and then my ring finger is already on my r key.
I was a big fish user for a while, went back to zsh once I hit enough frustrations… but now I’ve gone full xonsh. Python scripting is a much more fun experience, and the bash compatibility is really high.
I used to fiddle with shell configs, SSH terminal colors, and all of these settings to try to cobble together an experience on each machine that now I can have instantly by installing Fish.
I’ve been using Fish for a few years (daily light use) and I couldn’t be happier! It’s the terminal I always wanted, but never could figure out how to configure correctly :D
One of the great things about Shell is that you know that just about anyone who has a *nix machine will have Shell. This makes it very easy to write a quick script that anyone can use. This also means that makers of developer tools tend to write things in Shell and Bash without much consideration for alternative shells. Because of that, it’s basically impossible to use Fish in any default way or to write Fish scripts that other people can use.
You can have bash and fish installed at the same time, and every shell script I’ve encountered has #!/bin/sh or #!/bin/bash at the top to select the shell it’s written for, so my usage of fish has never interfered with running a script.
I used fish for a while, but couldn’t get over the lack of POSIX compatibility. Lots of stuff executes shell scripts with $SHELL. This means, when $SHELL changes, you either have to rewrite all those scripts into fish syntax, or configure the services individually to use /bin/sh instead of $SHELL to execute scripts.
Couldn’t you export
SHELL=/bin/shas part of the fish startup script? There may be some trickery to make sure that interactive shells aren’t spawned with /bin/sh, but it seems possible in principle.I don’t know. I just concluded that the system heavily assumes you’re using a POSIX compatible shell, saw close to no advantage to use a non-compliant shell (my collection of shell scripts will stay with she or bash, I don’t want to rewrite them all or lock myself in to fish) and I already know the posix shell syntax, and switched back to zsh.
EDIT: I now remember what in particular was breaking. I’m using sxhkd (simple X hotkey daemon) which lets you run commands when you press hotkeys. It interprets the command with $SHELL by default, and thus a lot of my hotkeys subtly broke in unexpected ways.
Even in interactive use I kept tripping up on lack of POSIX compatibility. Unfortunately I have too much muscle memory and still occasionally use bash/zsh when ssh’d in to servers in order to switch. I wish they’d consider an off-by-default env var to support POSIX syntax, but I understand it greatly complicates things.
I just see this as a parsing problem, not an architecture one, where POSIX-compatible syntax is merely a skin atop the niceties of the fish shell.
$SHELLbeing a POSIX-compatible shell isn’t mandated by any of the POSIX/SUS standards, is it?It isn’t mandated that your $SHELL be POSIX-compatible, but POSIX “utilities” are allowed to “behave differently” if it isn’t:
That’s fairly vague, but seems to leave open the possibility that you can have a POSIX-conformant operating system where the included utilities are allowed to depend on $SHELL being POSIX-compatible, and might behave badly if it isn’t. In practice I would be surprised if any modern Unixes do this. It’s considered good practice to explicitly specify
/bin/shwhen you want to execute a POSIX shell script, especially if you’re an OS-level utility.fizshis another good choice. It takes heavy influence fromfishwhile retaining a POSIX-compatible syntax, something that a lot of people in the comments here seem to miss.I love fish, I used it for a long time and still recommend it constantly. I use zsh now because my job is heavy on bash scripting, and I found myself running bash inside fish more and more often to get access to those scripting primitives. For anyone else who needs bash, but loves fish, I recommend zsh-autosuggestions, zsh-history-substring-search, and zsh-syntax-highlighting.
I tried fish shell for some time and really wanted to like it. In the end, I went back to (my tweaked out) zsh for several reasons:
I still recommend fish to people who don’t use the shell much anyway, and have a much better experience with default fish than default bash or zsh.
So you made an alias gl and that is so long you need to autocomplete it? or am i missing something?
You’re missing that
git pulltakes options, a repository, and a refspec.This. Fish does complete
glitself just fine, just notgit pull’s arguments.I think they mean the options to
git pull, which is the command gl calls.In particular, I’ve found this zsh plugin to work very well for history search in my setup.
No fzf for you? I love it.
I’ve been using fish for a couple of years now and I love it not only because of its batteries-included nature (I have a few custom functions I wrote, but otherwise I’ve been basically running vanilla fish from the beginning), but also because of how damn fast it is while providing all of these great features out of the box. For bash utility compat. there’s bass but I’ve never really had to use it. virtualfish is a fantastic replacement for virtualenvwrapper.
I used fish for a little bit, but found the effect of accidentally using the wrong syntax when on a random server to be pretty frustrating. I was actually typing more characters for for-loops on average than bash/zsh, due to not remembering what machine I was on. For me, the blissful ignorance of a less-elegant standard comes out a bit ahead. The up arrow for recall is also harder for me to hit than C-r, which I can hit with a 1-key-distance tap, as I map capslock to Ctrl, and then my ring finger is already on my r key.
C-p works as well for history search. Similarly, C-f works like right arrow for autocompletion.
I’ve been using fish for a while but I learnt from this post about the context sensitive auto completion.
I was a big fish user for a while, went back to zsh once I hit enough frustrations… but now I’ve gone full
xonsh. Python scripting is a much more fun experience, and the bash compatibility is really high.I used to fiddle with shell configs, SSH terminal colors, and all of these settings to try to cobble together an experience on each machine that now I can have instantly by installing Fish.
I’ve been using Fish for a few years (daily light use) and I couldn’t be happier! It’s the terminal I always wanted, but never could figure out how to configure correctly :D
One of the great things about Shell is that you know that just about anyone who has a *nix machine will have Shell. This makes it very easy to write a quick script that anyone can use. This also means that makers of developer tools tend to write things in Shell and Bash without much consideration for alternative shells. Because of that, it’s basically impossible to use Fish in any default way or to write Fish scripts that other people can use.
You can have bash and fish installed at the same time, and every shell script I’ve encountered has
#!/bin/shor#!/bin/bashat the top to select the shell it’s written for, so my usage of fish has never interfered with running a script.Better to use
#!/usr/bin/env bash. On BSD (and other) systems bash isn’t in/bin.