6

I added two new lines to my .bashrc so that Bash can find my Go programs:

GOROOT=/Users/jay/work 
PATH=$PATH:$GOROOT/bin 

But as a result, when I launch Emacs, Emacs hangs for several minutes and I get this error:

Tramp: Opening connection for bin using ssh...
Tramp: Sending command `exec ssh   -o ControlMaster=auto -o ControlPath='tramp.%C' -o ControlPersist=no -e none bin'
Tramp: Waiting for prompts from remote shell...
Tramp failed to connect.  If this happens repeatedly, try
    `M-x tramp-cleanup-this-connection'
Tramp: Waiting for prompts from remote shell...failed
Tramp: Opening connection for bin using ssh...failed

In a previous question, I found that a path declaration in my .bashrc file caused Tramp to hang. The line was this:

export PATH="$PATH:$HOME/.rvm/bin" # Add RVM to PATH for scripting

That time, I resolved the issue by simply removing the line, since it didn't seem necessary. But this time I kind of need these path declarations.

How do I resolve this error without deleting this path declarations from my .bashrc?

incandescentman
  • 4,111
  • 16
  • 53
  • 1
    In your previous question, you determined that: "*The message `Sending command 'exec ssh -e none bin'` is a clue that an error is occurring when `exec-path-from-shell` reads the path from the shell environment.*" Perhaps the same library -- `exec-path-from-shell` -- is unable to handle your new addition to `.bashrc`? You could try closing out all buffers and then exit emacs, and then restart. And you could also try disabling the library `exec-path-from-shell`. I realize it is a popular library, but there are other methods to set the $PATH in Emacs if that library is causing you problems. – lawlist Jun 24 '16 at 00:07
  • 1
    And, if you determine that `exec-path-from-shell` is the cause, then consider filing an issue with the author on Github. – lawlist Jun 24 '16 at 00:10
  • Thanks! Disabling `exec-path-from-shell` resolved the issue. – incandescentman Jun 24 '16 at 00:48

7 Answers7

11

I had this exact same problem but it had nothing to do with RVM on ( which I also have ) on my Ubuntu-16.10 machine. It was related to by custom prompt (PS1)

The issue was the prompt PS1.

This fix : https://stackoverflow.com/questions/6954479/emacs-tramp-doesnt-work

Essentially in your .bashrc

     case "$TERM" in
        "dumb")
            export PS1="> "
            ;;
        xterm*|rxvt*|eterm*|screen*)
            tty -s && export PS1="some crazy prompt stuff"
            ;;
    esac
Jimi
  • 111
  • 1
  • 3
  • Had the same problem with bash-it. Solved replacing your 6th line with `tty -s && source "$BASH_IT"/bash_it.sh` – Alberto Aug 09 '19 at 13:50
5

It looks like you've run the exec-path-from-shell from a Tramp buffer, so when it runs the shell, it attempts to do its magic on the remote server and then set the environment variables in your local emacs instance. That's almost certainly not what you want, and it's not a case that exec-path-from-shell is designed for. It looks like it's Tramp or your Tramp setup that's not working, though, because in theory any shell command we might execute locally should also work remotely, and that includes those issued by exec-path-from-shell.

sanityinc
  • 2,871
  • 13
  • 17
1

I ran into this problem, and the issue wasn't PS1--it had something to do with iterm's shell integration. The theory in this iterm2 bug report is that the escape characters used by the shell integration are confusing emacs.

A recent (not yet released) commit to the code disables shell integration for dumb terminals.

Before I saw that fix, I just changed this line in my .bash_profile:

test -e "${HOME}/.iterm2_shell_integration.bash" && source "${HOME}/.iterm2_shell_integration.bash"

to this, which disables integration if TERM=dumb:

if [ "$TERM" != "dumb" ]; then
    test -e "${HOME}/.iterm2_shell_integration.bash" && source "${HOME}/.iterm2_shell_integration.bash"
fi
John Wiseman
  • 111
  • 4
1

If the problem is your fancy custom prompt in the remote shell, an easy workaround is to add to your .bashrc or equivalent:

if [[ $TERM == "dumb" ]]; then
    export PS1="$ "
fi

After you define your PS1.

Note 1: the credit goes to ChasingLogic as this is their suggestion in this thread.

Note 2: I also posted this answer there.

prosoitos
  • 205
  • 3
  • 13
1

zsh users can use the following solution:

Today I finally took some time to fix a long-standing problem: when trying to edit a file on a remote host using Emacs tramp mode, long time-outs occurred when typing the remote file name (after hitting C-x C-f). These time-outs were so long and occurred after each key press that tramp was effectively useless.

After some digging (e.g. excluding helm as the problem source) I found this entry in the Emacs Wiki which basically told my that using zsh (the Z shell) on the remote host could be the culprit. Indeed, after adding

[[ $TERM == "dumb" ]] && unsetopt zle && PS1='$ ' && return at the top of my ~/.zshrc file solved the problem instantly. What this line does is simply replacing the shell prompt with a very simple one (a $ followed by a space) if the terminal is of the dumb type (which is the case for tramp).

Note : the credit goes to: https://blog.karssen.org/2016/03/02/fixing-emacs-tramp-mode-when-using-zsh/

Drew
  • 75,699
  • 9
  • 109
  • 225
Frank Wu
  • 51
  • 2
0

Another cause of this error:

On a first SSH connect to a server, new records are added to ~/.ssh/known_hosts.
But, if IP was specified in the connection instead of server's URL - only one line is added to ~/.ssh/known_hosts.
If subsequent connections in Tramp are made with server's URL, it hangs.

Solution: connect in terminal using URL(not IP) for a new line to be added in ~/.ssh/known_hosts.
Further connections in Tramp using URL should be successful.

0

I have used tramp to access files on remote computers on my (tiny) network for years. Recently, I updated operating systems (mint and trisquel), fussed around a bit - and tramp would no longer work: "Tramp: Waiting for prompts from remote shell...failed."

The clue came from a post here about PS1. The problem turned out to be that I changed the value of PS1 in my .bashrc, and that no longer was found by the value of shell-prompt-pattern set in my .emacs. As you can guess, this is completely "obvious" after a few hours of hair-tearing.

It is worth noting that the .bashrc change was something cute: colouring the prompt, which is useful in a Linux shell, but, as indicated, fools an emacs search.

This .bashrc entry works:

PS1="\h \u \w "

And this, which colours the user name (useful in a shell when changing to root and back), is the one that fools emacs:

PS1="\[\033[00m\]\h \[\033[01;31m\u\] \[\033[00m\]\w "

The .emacs entry that I use is this:

(setq shell-prompt-pattern "[Rhea|Thalia|Venus] [a-z]* ~ ")

dajo
  • 1
  • 1