Re: tramp (2.0.22); tramp errs: Remote `/bin/sh' didn't come up.

[Kai Großjohann]

Adrian Aichner <address@hidden> writes:

> Here you go:
>
> # Opening connection for address@hidden using scpx...
> # Waiting for prompts from remote shell
> # Waiting 60s for prompt from remote shell
> # Found remote shell prompt.
> # Initializing remote shell
> $ exec env PS1='$ ' /bin/sh
> # Waiting 30s for remote `/bin/sh' to come up...
> exec env 'PS1=$ ' /bin/sh
>
> $ $ [[Regexp `\(^[^#$%>
> ]*[#$%>] *\|^[^#$%>
> ]*[#$%>] *\)\'' not found in 30 secs]]

Okay, that's clear enough.  When you log in to the remote host using
the same method that Tramp uses (ie, via ssh, I guess), and then you
wait for a shell prompt, and then you type the same command that
Tramp sent, what do you see?

By clear enough, I mean the symptom, not the cause.  Tramp sends the
"exec env ... /bin/sh" command to start a Bourne-ish shell and then
it waits for a shell prompt from that shell.

But when Tramp did it on your system, the shell answered with TWO
shell prompts, not separated by newline.  (See the "$ $ " string.)

Do you have any idea how this could come about?

One possibility is that it is an end-of-line problem.  What's your
value of tramp-rsh-end-of-line?  If it is "\r\n" then it is
conceivable that the remote end sees two EOL characters in quick
succession and then produces two shell prompts right after each
other.  Does it help to frob tramp-rsh-end-of-line?  If so, is there
a way that Tramp could have auto-detected the right value to use?

You could of course doctor the symptoms by making it so that "$ $ "
is recognized as a shell prompt.  But I think it might be better to
get to the bottom of this.
-- 
A turnip curses Elvis