Tmux split window does NOT use current directory after installation of fish release 3

[CermakM]

Tmux split window does NOT use current directory after installation of fish release 3.

I tried setting the following from fish to bash, but the issue is the same. I don't know anything about the underlying connection of fish and tmux. However, this issue occured right after the installation of fish release 3.

set -g default-command /usr/bin/fish
set -g default-shell /usr/bin/fish

The relevant tmux config lines:

# Splitting to current directory instead of home dir
bind-key -r \ split-window -h -c "#{pane_current_path}"
bind-key -r - split-window -v -c "#{pane_current_path}"

Fish version

> fish --version
fish, version 3.0.2

Thanks for the help!

[faho]

There's no need to set both default-command and default-shell.

Doing so will end up running fish -c /usr/bin/fish, which is just wasteful.

Also it turns out that not doing it does not trigger the issue.

I'm not quite sure what's actually happening here, but that's a great workaround because it's what you should be doing in the first place.

[CermakM]

Right, gotcha.. Thank. This doesn't appear to have any impact on my site, however.
I did notice one thing, though. If I split the panes while having a running process in the terminal (i.e. vim), it actually splits into current directory.

[faho]

Okay, so, the way tmux reads the pwd for this is os-dependent and actually kind of weird.

On linux it boils down to readlink /proc/$pgroup/cwd. Where $pgroup is the pgroup in control of the terminal.

Which in case you're doing fish -c fish is the pid of the parent fish, because fish 3 stopped putting itself into a new pgroup in all cases.

If you use bash as default-shell, then that boils down to bash -c fish, only bash does an automatic exec in that case, so it appears to work.

If you run a command, that also works as fish puts it in its own pgroup in control of the terminal.

I'm unsure why in fish -c fish the outer fish doesn't do that to the inner one. I'm assuming it's to do with us basically not doing job control in non-interactive shells.

@mqudsi: Any ideas?

[CermakM]

Oh I see, you nailed it.. setting default-shell to bash and default-command to fish does the job. This is really fishy 😄

EDIT: I had to put both of these into .tmux.conf and source it in order for the changes to take place.

[faho]

setting default-shell to bash and default-command to fish does the job

@CermakM: Please try setting just default-shell to fish and leaving default-command undefined. That works for me, and seems like what you should do, normally.

[CermakM]

@faho, works now, after I've sourced the default-shell command .. now I can leave it out and the tmux still works as expected. Maybe uses some sort of cache / artifact mechanism? No idea.

[CermakM]

I did a clean reinstall to Fedora 30 and ran into the same issue once again. I managed to solve it by setting the default shell to be fish system-wise by running chsh -s /usr/bin/fish and completely removing the set -g default-shell /usr/bin/fish line from ~/.tmux.conf. Now it seems to work correctly.

[mrm1st3r]

I have the same issue after upgrading to Ubuntu 19.04, which upgraded fish to 3.0.2.
I use byobu as a tmux wrapper with it's default configuration.

I don't get the problem, if I'm running any application when splitting the window.

[mqudsi]

I'm unsure why in fish -c fish the outer fish doesn't do that to the inner one. I'm assuming it's to do with us basically not doing job control in non-interactive shells.

Yup. Which I tried changing in a local branch before the 3.0 release but that broke a few subtle things we don't have tests for (because our current test system doesn't make that easy). I don't know if there's a very small subset of actions we currently do in job control mode that we can safely do always, regardless of how fish is being invoked.

[fent]

I'm having the same issue. changing default-shell or default-command doesn't fix it :(

[evantravers]

I just started seeing something like this… it's really weird.

It happens even if I comment out my whole tmux.conf, but one thing I noticed is that if I'm currently running a command (like vim or less,) pane_current_path is set correctly… but if I'm in a blank fish shell, it doesn't work. Does that ring a bell for anyone?

I started to record an asciinema to demonstrate, but that weirded it out too. Here's a (too fast) screencast via gif…

[evantravers]

Another weird wrinkle for those still debugging this puzzle… pressing the binding that I have sends split-window -v -c "#{pane_current_path}" doesn't work, but sending the actual command split-window -v -c "#{pane_current_path}" does.

(I'm using https://github.com/tmux-plugins/tmux-pain-control for the binding for split…)

[fent]

after trying the previous solutions again, setting default-shell and unsetting default-command makes it work. and I didn't realize before that I had to set default-shell to fish's absolute path.

this will also only work after creating a new window. you can have it work on current windows by running fish on them

[evantravers]

@fent weirdly… that worked on one computer but not the other… I believe they share exactly the same dotfile�s… so I have no clue what's going on. ¯(°_o)/¯

[fent]

hmm, one thing I can think of is maybe you don't have your shell set to fish in the other computer, or an env variable is missing?

[evantravers]

both computers have the shell set to homebrew's version of fish:

~
❯ echo "$SHELL"
/usr/local/bin/fish

I track my dotfiles in git, so theoretically there shouldn't be anything in the fish directory that's not tracked… I believe all my shell variables are set by the fish_variables file, right?

[evantravers]

For anyone who cares… I thought that perhaps the difference between the two computers was that one was set up from scratch to use fish and the other had been lived in for a while… that wasn't it. I wiped the older computer and started from scratch and I still see the bug. ¯(°_o)/¯

[jtomaszewski]

My 3 cents: In my case, that line was the reason:

set-option -g default-command "reattach-to-user-namespace -l fish"

It was there to fix the pastebin on OS X . However, after removing it, the pastebin still works, and the problem from this issue also disappeared.

[evantravers]

@jtomaszewski are you using any plugins for tmux? I'm pretty sure that I get that setup through tmux-sensible, and I'm not sure how to overwrite it.

[jtomaszewski]

Not a plugin, just some my old dotfile .

[evantravers]

I'm just now testing this… and commenting out tmux-sensible seems to help me.

[MaxGyver83]

Same issue with fish 3.1.0.

[MaxGyver83]

Today at work, I noticed that everything was okay with set -g default-command /usr/bin/fish (and default-shell not set). The difference is that at work I haven't set fish as default shell in /etc/passwd.

Back at home, I set the default shell in /etc/passwd back to /bin/bash. So gnome-terminal started with bash again but tmux/byobu still started with fish, even after unsetting default-command and default-shell in tmux/byobu. So I logged out and in again. Now, new panes and windows start in the current directory.

That's ok for me. Now I use gnome-terminal for tmux (byobu) and I can set fish as default command in terminator when I don't want to use tmux.

But please tell me when you find tmux settings that work when fish is set as default shell (in /etc/passwd).

[bibstha]

@jtomaszewski 's comment in #5699 (comment) worked for me too.

[fent]

the commit referenced just above worked for me

[psychoslave]

Thanks @gpanders and @fent this gave me the keys to find a solution that worked for me, with specifications of my case detailed in #7017 that @faho just closed pointing me to here. Thanks @faho for the hint.

By the way, @evantravers, maybe your Tmux profile source a system file, whose content might vary from one system to an other? In my case byobu had source $BYOBU_PREFIX/share/byobu/profiles/tmux in the ~/.config/byobu/profile.tmux file, so default-command was set by the former. Thus said, set -e default-command after the source command didn't work, while the following did:

set -g default-shell /bin/sh
set -g default-command $SHELL

However in my case launching a bright new Byobu window happen to finish in a /bin/sh shell at the very first given prompt Any subsequently created Tmux pane does run Fish as expected, with the GNOME-terminal tacking into account PWD update correctly.

[psychoslave]

So, here is something is completely functioning (for me):

#!/bin/sh
:<<:about:
  Fix initial shell set up when opening a new a Tmux session.

  See https://github.com/fish-shell/fish-shell/issues/5699 for more information.

  This is intended to be used in combination with a Tmux configuration such as:
  set-environment -g ENV $HOME/.config/byobu/enforce_user_shell.sh
  set -g default-shell /bin/sh
  set -g default-command $SHELL

  NOTE: Fit ENV set up above to match the current script.
:about:

# If Tmux did `set -g default-shell /bin/sh`
[[ $SHELL = '/bin/sh' ]] || exit

# POSIX test for “$TERM starts with 'screen'”, matching "screen-256color" too
case "$TERM" in screen*) true ;; *) false ;;  esac || exit

# Open a new tmux window, not impacted by the bug, at position 0 and exit
tmux move-window -s0 -t2 && tmux new-window -t0 && exit

Now launching a new Byobu window will end up in a Fish session not affected by the bug. I had first attempted to launch fish in the provided sh, but this was still affected by the bug, unlike any further spawned shell pane. Note that the script need the ENV variable to point to itself: this is where POSIX shell will look for sourcing during initialization, according to bash manual.

[mk12]

I was running into this issue too. However, I don't care so much about having splits open in the same directory. I just want to easily be able to change a session's default directory (for splits and new windows). I'm sharing my solution in case it helps others.

You can change the directory with C-b :attach -c /path/to/dir inside a session. But it seems impossible to automate into a shortcut — running tmux attach tries to attach to a new session, not modify the session you're in. I've finally come up with a hacky solution, tmux-set-cwd.sh:

#!/bin/bash

if ! [[ -n "$TMUX" ]]; then
    echo "not in a tmux session" >&2
    exit 1
fi

TMUX= tmux attach -c "$(pwd)" -t . \; detach < /dev/null > /dev/null 2>&1 || :

This attaches to the current session with the -c option and immediately detaches. Importantly, the -c change will take effect in your current session (since it's a property of the session, not the client). The script redirects output to /dev/null (otherwise you get infinite recursion until it detaches), and also redirects input from /dev/null (otherwise I get weird control characters typed in my terminal after running the script).

So, you can run this script directly, or make an alias in your fish config for easy access.

[kfrncs]

Oh I see, you nailed it.. setting default-shell to bash and default-command to fish does the job. This is really fishy smile

EDIT: I had to put both of these into .tmux.conf and source it in order for the changes to take place.

Was having this issue on Arch! This fixed it.

[faho]

Fixed by a2e4869, like #7060.