GNU bug report logs - #78508
Tramp confused by bracketed paste after remote prompt

Previous Next

To reply to this bug, email your comments to 78508 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: Daniel Colascione <dancol <at> dancol.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Tramp confused by bracketed paste after remote prompt
Date: Tue, 20 May 2025 09:58:07 -0400

When the remote shell emits bracketed paste escape codes (as zsh does
even when TERM=dumb), tramp ends up timing out unable to find the shell
prompt on initial connection.

BTW: is there any particular reason that sshx uses RemoteCommand but ssh
method does not?

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 78508 <at> debbugs.gnu.org
Subject: Re: bug#78508: Tramp confused by bracketed paste after remote prompt
Date: Wed, 21 May 2025 09:35:10 +0200

[Message part 1 (text/plain, inline)]

Daniel Colascione <dancol <at> dancol.org> writes:

Hi Daniel,

> When the remote shell emits bracketed paste escape codes (as zsh does
> even when TERM=dumb), tramp ends up timing out unable to find the shell
> prompt on initial connection.

Have you checked the recipe from the Tramp manual in (info "(tramp)
Frequently Asked Questions") ?

--8<---------------cut here---------------start------------->8---
          When using zsh on remote hosts, disable zsh line editor
          because zsh uses left-hand side and right-hand side prompts in
          parallel.  Add the following line to ‘~/.zshrc’:

               [[ $TERM == "dumb" ]] && unsetopt zle && PS1='$ ' && return

          This uses the default value of ‘tramp-terminal-type’, "dumb",
          as value of the ‘TERM’ environment variable.  If you want to
          use another value for ‘TERM’, change ‘tramp-terminal-type’ and
          this line accordingly.
--8<---------------cut here---------------end--------------->8---

Note, that until recently TERM wasn't set properly initially, when
calling ssh. I have a WIP patch for this (being under regression test
for some days), see appended. Does this help?

> BTW: is there any particular reason that sshx uses RemoteCommand but ssh
> method does not?

Yes: They are different methods, and they are designed for this
difference. For example, using RemoteCommand disables direct async
processes for sshx connections.

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 78508 <at> debbugs.gnu.org
Subject: Re: bug#78508: Tramp confused by bracketed paste after remote prompt
Date: Thu, 22 May 2025 03:23:34 -0400

On May 21, 2025 3:35:10 AM EDT, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>Daniel Colascione <dancol <at> dancol.org> writes:
>
>Hi Daniel,
>
>> When the remote shell emits bracketed paste escape codes (as zsh does
>> even when TERM=dumb), tramp ends up timing out unable to find the shell
>> prompt on initial connection.
>
>Have you checked the recipe from the Tramp manual in (info "(tramp)
>Frequently Asked Questions") ?

It shouldn't be necessary to do that. Sometimes modifying the target system isn't all that straightforward, and control sequences should be straightforward to strip. There's already an attempt to strip ANSI color, yes? It's not like Tramp is trying to avail itself of the opportunities SSH provides to make noninteractive use feasible. Failure mode is just "when I try to use Emacs to connect to this family of hosts, it hangs. VSCode works. I guess I'll stick with that" 

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 78508 <at> debbugs.gnu.org
Subject: Re: bug#78508: Tramp confused by bracketed paste after remote prompt
Date: Thu, 22 May 2025 13:25:47 +0200

Daniel Colascione <dancol <at> dancol.org> writes:

Hi Daniel,

>>> When the remote shell emits bracketed paste escape codes (as zsh does
>>> even when TERM=dumb), tramp ends up timing out unable to find the shell
>>> prompt on initial connection.
>>
>>Have you checked the recipe from the Tramp manual in (info "(tramp)
>>Frequently Asked Questions") ?
>
> It shouldn't be necessary to do that. Sometimes modifying the target
> system isn't all that straightforward, and control sequences should be
> straightforward to strip. There's already an attempt to strip ANSI
> color, yes? It's not like Tramp is trying to avail itself of the
> opportunities SSH provides to make noninteractive use feasible.

Tramp won't go into the prompt parsing business. Filtering ANSI color
sequences out was a compromise a while ago. You let feel me that it was
an error to do so.

> Failure mode is just "when I try to use Emacs to connect to
> this family of hosts, it hangs. VSCode works. I guess I'll stick with
> that"

That's unfair, and you know it.

Have you tried the patch I've shown?

Best regards, Michael.

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 78508 <at> debbugs.gnu.org
Subject: Re: bug#78508: Tramp confused by bracketed paste after remote prompt
Date: Thu, 22 May 2025 12:02:01 -0400

[Message part 1 (text/plain, inline)]

On May 22, 2025 7:25:47 AM EDT, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>Daniel Colascione <dancol <at> dancol.org> writes:
>
>Hi Daniel,
>
>>>> When the remote shell emits bracketed paste escape codes (as zsh does
>>>> even when TERM=dumb), tramp ends up timing out unable to find the shell
>>>> prompt on initial connection.
>>>
>>>Have you checked the recipe from the Tramp manual in (info "(tramp)
>>>Frequently Asked Questions") ?
>>
>> It shouldn't be necessary to do that. Sometimes modifying the target
>> system isn't all that straightforward, and control sequences should be
>> straightforward to strip. There's already an attempt to strip ANSI
>> color, yes? It's not like Tramp is trying to avail itself of the
>> opportunities SSH provides to make noninteractive use feasible.
>
>Tramp won't go into the prompt parsing business. Filtering ANSI color
>sequences out was a compromise a while ago. You let feel me that it was
>an error to do so.

We live in a world in which people spew hard coded terminal escape sequences constantly, often without regard for isatty, TERM, or basic common sense. Tramp can either work or refuse to work. It's no excuse to say people are just all holding it wrong when other systems that talk to shells work fine.

>> Failure mode is just "when I try to use Emacs to connect to
>> this family of hosts, it hangs. VSCode works. I guess I'll stick with
>> that"
>
>That's unfair, and you know it.

It's not only fair, but an accurate paraphrase of what's actually happened.

>Have you tried the patch I've shown?

Doesn't help. This system emits the control codes regardless of TERM. Is that wrong? Yes. Are people going to stop? No, they are not. 

[Message part 2 (text/html, inline)]

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 78508 <at> debbugs.gnu.org
Subject: Re: bug#78508: Tramp confused by bracketed paste after remote prompt
Date: Thu, 22 May 2025 18:59:00 +0200

Daniel Colascione <dancol <at> dancol.org> writes:

Hi Daniel,

>>Tramp won't go into the prompt parsing business. Filtering ANSI color
>>sequences out was a compromise a while ago. You let feel me that it was
>>an error to do so.
>
> We live in a world in which people spew hard coded terminal escape
> sequences constantly, often without regard for isatty, TERM, or basic
> common sense. Tramp can either work or refuse to work. It's no excuse
> to say people are just all holding it wrong when other systems that
> talk to shells work fine.

I said "Tramp won't go into the prompt parsing business." It doesn't
mean, that Tramp couldn't use an existing function to do the job.

What we have is shell-prompt-pattern, which doesn't fit your request.

>>Have you tried the patch I've shown?
>
> Doesn't help. This system emits the control codes regardless of TERM.
> Is that wrong? Yes. Are people going to stop? No, they are not. 

You fail to show a recipe for this problem, that I could work on. At
minimum, an Emacs session started with "-Q", and a Tramp debug buffer
with tramp-verbose set to 10.

Best regards, Michael.

Message #25 received at 78508-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 78508-done <at> debbugs.gnu.org
Subject: Re: bug#78508: Tramp confused by bracketed paste after remote prompt
Date: Sat, 31 May 2025 15:06:41 +0200

Version: 31.1

Hi Daniel,

>>> Have you tried the patch I've shown?
>>
>> Doesn't help. This system emits the control codes regardless of TERM.
>> Is that wrong? Yes. Are people going to stop? No, they are not. 
>
> You fail to show a recipe for this problem, that I could work on. At
> minimum, an Emacs session started with "-Q", and a Tramp debug buffer
> with tramp-verbose set to 10.

No further response. I've pushed the patch to the repositories, closing
the bug. Pls reopen only if you have a recipe we could work on.

Best regards, Michael.

Previous Next

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