Talk:Fish

Also check $TERM in .bashrc before dropping into fish?

If it's `dumb`, we shouldn't process then.

Command to add to $PATH is redundant

The command to add some directories to $PATH depicts default behaviour when submitting a flag that is already assumed. The -p flag could be completely skipped and the command would still do just fine [1]. Adam6 (talk) 14:08, 5 December 2024 (UTC)

seem like something is wrong in Fish#Modify_.bashrc_to_drop_into_fish

in the line if [[ $(ps --no-header --pid=$PPID --format=comm) != "fish" && -z ${BASH_EXECUTION_STRING} && ${SHLVL} == 1 ]]

the test ${SHLVL} == 1 should be something like ${SHLVL} == [1,2] because when loggin in from tty, $SHLVL is 1, but when inside a gui session launched from terminal emulator, $SHLVL is 2 and exec fish is not ran Pigeon (talk) 20:37, 24 May 2025 (UTC)

I'd like to add to that. I'm using KDE and tried to use it this tip for starting fish in terminals. This works fine for the current session, but on the next login, I got a black screen. After lots of trial and error found this snippet to be the culprit. A possible alternative for Alacritty users is to add fish as your terminal shell in alacritty.toml

[terminal]

shell = "fish" Awlexus (talk) 00:37, 26 July 2025 (UTC)

Hey! I've been messing with this script and cannot reproduce the $SHLVL variable becoming equal to 2.

I've tried:

- Dropping into bash after logging in to from the tty,

- fromssh,

- entering bash from within the graphical session with {foot,alacritty,ghotty,kitty}

... it always produces normal behavior: $SHLVL equals to 1

I begin suspecting that when i started this discussion, the issue was caused by tmux

I think that the {{accuracy}} flags can be removed from this section? Pigeon (talk) 15:50, 16 January 2026 (UTC)

OK, seems that i've figured out the cause. If you login on tty (don't use display manager), check how you start your gui session. If you start with exec (e.g. exec sway) $SHLVL will be 1, but if you start without exec (what you probably shouldn't do anyway, for security reasons) SHLVL=1 gets assigned when you're in tty and increases to 2 when you launch terminal in GUI session.

Somebody check if that's what causes $SHLVL inconsistency and then this discussion can be closed?

I've added check [[ ${SHLVL} == [1,2] ]] to the wiki page. Pigeon (talk) 18:09, 16 January 2026 (UTC)

provided .bashrc is questionable

Sorry, i'm opening another discussion on the same section (as i see them as separate topics).

I kind of don't trust the recommendations in this script: first, it suggested checking BASH_EXECUTION_STRING with poor justification and it turned out to be unneeded (check my edits from Jan 16).

And now, the current version suggests the following check:

shopt -q login_shell && LOGIN_OPTION='--login' || LOGIN_OPTION=''
exec fish $LOGIN_OPTION

with the following justification:

• In order to let fish know whether it is a login shell, you can detect login shell status in ~/.bashrc and pass on the --login option to fish. The fish shell command status can be used to show the status.

The problem is, it doesn't explain why that's needed. Official fish documentation doesn't really explain --login option either.

So i went ahead and removed it. I've been daily driving the following ~/.bashrc:

if grep -qv 'fish' /proc/$PPID/comm && [[ ${SHLVL} == [1,2] ]]; then
    exec fish
fi

for more than a week already and nothing has changed (in a good sense).

Important to note my setup:

• I don't use login manager, i login on tty.
• In ~/.bash_profile i do source ~/.bashrc.
• (and then, from tty, i exec hyprland)

---

So I suggest that we remove this check.

OR

I might of course be wrong and it just happens to not clash with my setup that i don't stumble upon the pitfall that removing --login check creates. In such case, please someone add an explanation why this check is needed for those like me who doesn't like blindly copying stuff from the wiki not understanding how it works. Pigeon (talk) 16:43, 24 January 2026 (UTC)

Hi. I'm the new @Pigeon (new account). Still on my way to spare people from copy-pasting bad scripts from wikis :-) (though note that i am by no means an expert too, thus i reach here for a prior discussion).

I've been using the aforementioned bashrc script for almost 4 months with a few different usage scenarios and can say that the $LOGIN_OPTION check that we suggest at the moment is doing nothing. Searching through the official fish github repo and docs i didn't find anything that suggests that this check is needed.

If nobody is against (i don't see any activity after my (@Pigeon's) last edits), i'll remove it from Fish#Modify_.bashrc_to_drop_into_fish. There is also a NixOS Wiki Fish page that i also contribute to and it used to borrow the script from ArchWiki. Now that i would like to improve both, i link this talk page there and will link the NixOS Wiki .bashrc discussion here. CPP (talk) 21:40, 13 May 2026 (UTC)

Additional note (what i maybe would like to mention somewhere on the page): it is common to source ~/.bashrc in ~/.bash_profile. But some people (me included) forget to add an "is-interactive?" check (e.g. [[ $- == *i* ]] || return and, as a result, the exec fish may execute in unwanted places. For example, systemd units that start bash with --login option will be broken by the exec fish that gets triggered on sourcing ~/.bashrc CPP (talk) 21:48, 13 May 2026 (UTC)

Other users noted the sourcing issue too. For sure go ahead, if you can fix the subject you linked here. --Indigo (talk) 19:54, 17 July 2026 (UTC)