Is it really a “bug” if you’re writing incompatible code for Fish? Bug implies unexpected behaviour but I’d argue that Fish’s non-POSIX behaviour is well discussed, documented, and thus should be completely expected.

AFAIR the problems using fish tend to be when other programs (e.g. vim or whatever) try and interact with the shell and it's non-POSIX compliant.

The "expect it to work, didn't" is more on the user's side, going from e.g. bash to fish.

I know it was just an example but on any Vi clone you can set the default shell:

   :set shell=/bin/bash

For interactive shells do not matter if is not POSIX compliant. I use csh (the really old one) as interactive shell.

Yes and no. One nice thing about shell, is that you can log your commands/look at your history - and easily automate tasks (turn an interactive session into a script).

The only trouble is, such snippets have a way of sneaking into documentation, ci pipelines and other places.

And then non-posix isn't quite as nice anymore. Even if csh or fish might be the nicer language.

I do think the oil shell project is on the right track, by trying to "fix" shell (and fish is a great source of inspiration for the interactive part).

Still, when plan9 didn't manage to take over, I guess I'm a bit sceptical about any new shell having much success...

It matters a lot when dealing with default environment variables. Even when expanding $PATH fish will give you much headache.

I recommend leaving bash as your system shell and just telling your terminal emulators to start with fish.

Those are probably bugs you could report to the project.

They're intentional.

They have considered a compatibility layer in the past:

https://github.com/fish-shell/fish-shell/wiki/POSIX-compatib...