One of the nice things of fish is that we don't have anything as complicated as the bash man page's "INVOCATION" section in our documentation.

"If it's a non-interactive shell, it does not read bashrc, except when it has been invoked by ssh or rshd, unless it is invoked as sh".

We always read config.fish, and that's nice.

However, as we see in e.g. #5246 and #4432, doing that even when non-interactive can cause some issues. Issues that we currently expect the user to expect, and guard against with if status is-interactive.

And I'm not really sure if configuration of non-interactive shells is ever really wanted? If you execute a script via fish /path/to/script (or directly via the shebang), you expect a consistent environment.

So, I would argue that we should possibly change this:

• Don't source /etc/fish/config.fish and ~/.config/fish/config.fish (the one in /usr can stay, but that's not really "config")

• Don't read snippets (which are technically in /usr/share/fish/config.fish)

• Don't add the user's functions (in $HOME and /etc) to $fish_function_path

Now, obviously this complicates the logic a bit. It's "if fish is interactive, read config.fish, if not, don't" instead of just "read config.fish". I'd argue that it's still quite simple, and helps unbreak things that are currently quite easy to break - understanding that stty touches the terminal is advanced stuff.

Additonally, if configuration of non-interactive shells is wanted (and I don't see how, given that bash doesn't have it), we could add a "config-noninteractive.fish", or simply expect users to run fish -C 'source ~/.config/fish/config.fish.