christoomey / vim-tmux-navigator

Seamless navigation between tmux panes and vim splits
MIT License
5.25k stars 322 forks source link

problems with `sudo vim` #119

Open doronbehar opened 8 years ago

doronbehar commented 8 years ago

Great Extension, but I think this small issue is annoying but easy to be fixed.

Let's say I have 2 tmux panes divided to up and bottom. Consider the following being done on the upper pane:

  1. If I run vim -O hello world I can switch between vim's windows - everything works fine.
  2. If I run sudo vim -O hello world as myself, I can't switch with <C-l> and <C-h> between vim's windows
  3. If I'm root (I ran sudo su before), and I run vim -O hello world, I can switch between vim's windows <C-l> and <C-h> but I can't switch to tmux's pane at the bottom.
  4. If I'm root because I ran sudo su or su root, I can run zsh --login and vim -O hello world and then everything works fine like I'm myself and not root.
  5. If I ran su <myusername>, I don't have all my environment variables and aliases defined like always but if I run afterwards vim -O hello world, I can switch to tmux's pane at the bottom with <C-j>.

Note: All of my important dotfiles are linked from my $HOME to /root and it includes:

  • ~/.vimrc
  • ~/.vim/
  • ~/.tmux.conf
  • ~/.tmux/ # a directory where I keep plugins for tmux

Not sure if it's releavent but I keep these are linked as well:

  • ~/.zshrc
  • ~/.zshenv
  • ~/.zprofile
  • ~/.zlogin
christoomey commented 8 years ago

Hey @Doron-Behar, thanks!

Regarding the issues you're seeing, I'm guessing they're related to the process listing, rather than anything to do with your user settings.

Can you try the first step outlined in the Troubleshooting section to help narrow down?

blueyed commented 8 years ago

Interesting. It also does not work with https://github.com/christoomey/vim-tmux-navigator/pull/117: the script detects that Vim is running, but the actual send-keys c-h is not handled by Vim?! You can try it from tmux' command mode (<c-b> : by default): :send-keys c-h does nothing, but :send-keys c-w c-h works. :send-keys :TmuxNavigateLeft c-m also works (that's what is mapped to from <c-h>).

And it's actually only a problem with Neovim (v0.1.3-384-g47d44e0), but not Vim (7.4.1689) for me.

@Doron-Behar Are you using Neovim or Vim? Which version?

blueyed commented 8 years ago

The <c-h> gets interpreted as <bs> with sudo nvim.. You can check this after <c-v> in Neovim's insert/command-line mode: <c-v><c-h> prints <BS> for me.

blueyed commented 8 years ago

The Neovim issue is https://github.com/neovim/neovim/issues/2048.

blueyed commented 8 years ago

@Doron-Behar See https://github.com/neovim/neovim/issues/2048#issuecomment-212135388. Also with Vim, the terminfo might be relevant.

blueyed commented 8 years ago

Duplicate of https://github.com/christoomey/vim-tmux-navigator/issues/71#issuecomment-202422963.

christoomey commented 8 years ago

Per @blueyed's comment, this seems to be duplicate of #71, related to an issue with Neovim, and not this plugin directly. I'm going to close this now based on that, but please feel free to comment or reopen if I've missed something.

doronbehar commented 8 years ago

Sorry for not replying a long time, I use Vim - no Neovim

blueyed commented 8 years ago

It might be a similar issue though: c-j does not get through to vim.

Please investigate using c-v, and also by executing the tmux-navigator commands manually.

doronbehar commented 8 years ago

Ok, Here is my Report: :send-keys c-[hjkl] from within tmux as well as :TmuxNavigate* from within vim brings me to the correct pane/window. It means vim handles this plugin better compared to neovim right?

christoomey commented 8 years ago

Hey @Doron-Behar, sorry for the confusion. I'll reopen this now and hopefully we can sort it out.

doronbehar commented 8 years ago

Update:

I just installed neovim and tested the same issue with sudo nvim file. Surprisingly, in contrast of what you said about an opened issue with neovim, I didn't experience the same problem like with vim. -- Perhaps it's another good reason to use neovim and not vim.

smkent commented 8 years ago

In vim, vim-tmux-navigator looks for the active tmux socket in the TMUX environment variable. When invoked using sudo, the environment is typically sanitized or reset (via env_reset in /etc/sudoers). Therefore, vim invoked via sudo doesn't know that it's in a tmux session, and CTRL+[hjkl] aren't passed onto tmux by vim.

To immediately work around this issue, the TMUX environment variable should be preserved when starting a root shell or invoking vim as root using sudo. You can preserve the entire environment with:

sudo -E vim

or just the TMUX environment variable with:

sudo TMUX="${TMUX}" vim

(assuming this is allowed by your machine's /etc/sudoers configuration).

blueyed commented 8 years ago

@smkent Good find.

I wonder why it works for @Doron-Behar with Neovim though.. do you have $TMUX set in that case?!

I don't think there is much we can do about it, apart from adding something to the README, is there?

smkent commented 8 years ago

I don't think there is much we can do about it, apart from adding something to the README, is there?

sudo sets the SUDO_USER and SUDO_UID environment variables. The vim-tmux-navigator vim plugin could be modified to look for the default tmux socket path at /tmp/tmux-${SUDO_UID}/default. Unfortunately this still isn't a reliable solution, because it assumes 1) the user's tmux socket is in the standard location (tmux allows a different socket path to be specified using -S) and 2) that the current SUDO_UID is the original user (invoking sudo within a shell started with sudo overwrites SUDO_USER and SUDO_UID).

I think the best solution would just be to mention the workarounds in the README. We could also recommend adding env_keep += "TMUX" to /etc/sudoers, but I don't know if that introduces security or compatibility issues.

jamespharvey20 commented 5 years ago

I don't think there is much we can do about it, apart from adding something to the README, is there?

Still not in the README. Spent quite a while tracking down what seemed to me like an intermittent problem, including adding debug code to the plugin, before it hit me that it was only the sudo vim windows malfunctioning, then ran across this issue.

doronbehar commented 5 years ago

Additionally, I would recommend another workaround to be mentioned in the README (which should be suitable for Neovim as well because of https://github.com/neovim/neovim/issues/1716) - Use a plugin such as https://github.com/tpope/vim-eunuch or https://github.com/lambdalisue/suda.vim which provide a :SudoWrite and :SudoRead like commands.

randomizedthinking commented 5 years ago

@doronbehar the issue being discussed breaks https://github.com/tpope/vim-eunuch that :SudoWrite is no longer working under neovim. https://github.com/lambdalisue/suda.vim is a work-around, yet user needs to input password each time when saving a file.

jamespharvey20 commented 5 years ago

I make no argument if this is a good fix for everyone, or if it should be recommended. I make a lot of /usr/local/bin/ "wrappers" for things, so I lean this way. This builds off one of the comments by @smkent

/usr/local/bin/sudo

#!/usr/bin/bash

if [[ -v TMUX ]]; then
   /usr/bin/sudo TMUX="${TMUX}" "$@"
else
   /usr/bin/sudo "$@"
fi

It obviously requires /usr/local/bin/ be in $PATH, and before /usr/bin/. Those with other shells would need to tweak as appropriate, or with older bash would need to use:

if [[ -z ${TMUX+x} ]]; then
doronbehar commented 5 years ago

@randomizedthinking I've had this discussion on https://github.com/lambdalisue/suda.vim/pull/3 about the seemingly lack of password cache which was supposed to be fixed in https://github.com/neovim/neovim/pull/8389 which wasn't yet merged.