bug#46466: 28.0.50; Tramp hangs with bad prompt even when using /bin/sh

[Michael Albinus <michael.albinus@gmx.de>]

Erik Hetzner <egh@e6h.org> writes:

> Hi Michael,

Hi Erik,

>> What is /bin/sh, both locally and remote? In my case, running Fedora 33,
>> I see
>>
>> --8<---------------cut here---------------start------------->8---
>> # ls -l /bin/sh
>> lrwxrwxrwx. 1 root root 4 Jul 27  2020 /bin/sh -> bash
>> --8<---------------cut here---------------end--------------->8---
>
> Good question, I should have mentioned that. I have tested this on
> both debian and ubuntu, where /bin/sh is linked to dash
>
> $ ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 Dec 10 05:23 /bin/sh -> dash

Hmm, this doesn't count then. You have reported, that .bash_profile was
used for user "test". What is the default shell for that user?

> As a follow up, I suspect that in some way this is expected behavior.
> I see that the *sshx* connection method specifies the shell to run
> when connecting, whereas the *ssh* connection method connects without
> specifying a command, and therefore starts a default remote shell.

"sshx" is for special cases, where the default values of "ssh" don't work.

> This suggests a fix which turns out to works. The behavior is fixed,
>  for me, by adding `("-o" "RemoteCommand='%l'")` to the list of
> `tramp-login-args' for `tramp-methods' (see below).

We cannot hijack the argument "RemoteCommand" by default. There are
several reasons.

- People might have own values for that argument. For example, on my
  QNAP NAS devices it isn't possible to use ssh out-of-the-box for
  scripting, because QNAP starts the "Console Management" program, which
  is in the way. In order to fix this, I have added for all my QNAP NAS
  devices the following line in the respective .ssh/config entries:

        RemoteCommand /bin/sh -noprofile -noediting -norc -i

- If the RemoteCommand argument is set, it isn't possible any longer to
  use direct async processes in Tramp. See (info "(tramp) Remote processes")

> It is also possible to set the PS1 value directly with this remote
> command, e.g. `("-o" "RemoteCommand='PS1=\"$ \" %l'")`, which might
> provide even more safety against unusual prompts.

Maybe, but this should be better done with the SetEnv argument.

> Is this a patch that would be welcome? It would fix cases where users
> had more elaborate prompts in their default shell and where /bin/sh
> was a simpler shell (debian and ubuntu, at least). Unusual prompts are
> more and more popular, but users to do not usually enable them for
> /bin/sh. However, it might have effects that I am not aware of.

As said, the patch cannot be applied as-is. However, I'm open for all
proposals, because this is indeed a common problem users blame Tramp about.

> best, Erik

Best regards, Michael.