search

purcell / exec-path-from-shell

Make Emacs use the $PATH set up by the user's shell
Other
1.43k stars 82 forks source link

Broken tramp password prompt on Emacs 27 #95

Closed wyuenho closed 4 years ago

wyuenho commented 4 years ago

So these 2 bugs I describe are a bit weird, I've reported this to the emacs devs but they've suggested me to report it here, so please bear with me:

Bug 1

  1. $ echo 'PATH=".:$PATH"' > .bash_profile

  2. $ echo '(require 'exec-path-from-shell)(exec-path-from-shell-initialize)' > .emacs

  3. Launch /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs in GUI

  4. C-x C-f /sudo:: RET

  5. Cursor now stops blinking but no password prompt is shown.

  6. If you TAB complete after /sudo: but before the final :, prompt will not be stuck

This bug can only be reproduced if steps 1-3 are followed exactly. The following examples can't reproduce this problem:

There's some very weird interactions with how Emacs starts up, what happens to Emacs after call-process on SHELL and setting exec-path, and tab completion of /sudo:: in the minibuffer. This appears to have been the case since relatively early versions of Emacs 27.

Workaround

If auth-sources is set to '("~/.authinfo.gpg") and ~/.authinfo.gpg has saved the credentials of localhost or the machine's host name, bug 2 does not happened.

Bug 2

  1. Same as Bug 1

  2. $ echo '(require 'exec-path-from-shell)(exec-path-from-shell-initialize)(require 'crux)' > .emacs

  3. Same as Bug 1

  4. Same as Bug 1

  5. M-x crux-sudo-edit

  6. Minibuffer now stuck at "Tramp: Sending Password"

Same workaround works for this bug.

I was wondering if you have any idea what's going on with emacs-27's call-process, as in why exec'ing the shell before and after changes emac's behavior?

purcell commented 4 years ago

exec-path-from-shell is not doing anything exotic, just setting exec-path.

When running, exec-path-from-shell does call functions in other libraries which would cause them to get loaded, e.g. file-remote-p potentially causes parts of tramp or the GPG-handling libraries to be loaded. Now, if those libraries are configuring themselves at load-time based on whether they find certain executables on the exec-path, then they might come to the wrong conclusions. So the sequence might be:

  1. exec-path-from-shell.el starts loading
  2. Other libraries load and find certain executables present or missing (e.g. ssh, gpg, the shell)
  3. exec-path-from-shell.el changes exec-path
  4. Functions in other libraries get confused or misbehave.

If that's the case, it's an Emacs bug, or at least not really an exec-path-from-shell bug. But you might also consider enabling exec-path-from-shell-debug to see what exec-path-from-shell is doing.

wyuenho commented 4 years ago

Yeah I thought it's probably not exec-path-from-shell. I've tried turning on exec-path-from-shell--debug, but there's nothing interesting. Sadly, I can't edebug-defun file-remote-p, as redisplay_internal appears to keep calling it so I can't progress once I'm in there.

I've filed bug 39389 to emacs, would appreciate you replying if you have the time.

wyuenho commented 4 years ago

Ok this is entirely Emac's problem. Closing this.

purcell commented 4 years ago

Ah, good work tracking that down.