GNU bug report logs - #46466
28.0.50; Tramp hangs with bad prompt even when using /bin/sh

Previous Next

Full log

Message #19 received at 46466 <at> debbugs.gnu.org (full text, mbox):

From: Erik Hetzner <egh <at> e6h.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 46466 <at> debbugs.gnu.org
Subject: Re: bug#46466: 28.0.50;
 Tramp hangs with bad prompt even when using /bin/sh
Date: Sun, 14 Feb 2021 09:28:20 -0800

Hi Michael,

On Sun, 14 Feb 2021 06:37:29 -0800,
Michael Albinus <michael.albinus <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.