[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: |
Erik Hetzner |
Subject: |
bug#46466: 28.0.50; Tramp hangs with bad prompt even when using /bin/sh |
Date: |
Sun, 14 Feb 2021 09:28:20 -0800 |
User-agent: |
Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (Gojō) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) |
Hi Michael,
On Sun, 14 Feb 2021 06:37:29 -0800,
Michael Albinus <michael.albinus@gmx.de> wrote:
>
> […]
>
> 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?
Sorry, I also should have mentioned that! The default shell is bash,
which seems to be the underlying issue. tramp starts a bash shell
before execing /bin/sh.
> […]
>
> 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")
I see, thanks!
> > 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.
Thank you so much for these explanations. Tramp is a great product and
I know that it has made a lot of accommodations to a heterogeneous
environment to make it work so well! I’ll keep exploring possible
solutions for this. In the end, it might just be a suggestion in the
manual or improvements to error reporting.
Thanks again for your help.
best, Erik