[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46466: 28.0.50; Tramp hangs with bad prompt even when using /bin/sh
From: |
Michael Albinus |
Subject: |
bug#46466: 28.0.50; Tramp hangs with bad prompt even when using /bin/sh |
Date: |
Sun, 14 Feb 2021 15:37:29 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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.