[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OK, lets get this to work!!

From: Michael Albinus
Subject: Re: OK, lets get this to work!!
Date: Fri, 23 Nov 2012 14:37:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

[Cc tramp-devel, for the archives]

address@hidden writes:

> Hello Michael,

Hi Gérald,

> I logged successfully on your machine, both from a native Windows commamd
> window and from an emacs shell.  From the Windows command window I got a
> normal prompt, from the Emacs shell I got two prompts, on two different
> lines, as we did when logging on the Linux local server here!!!  I did "ls"
> from the two shells and got the same thing happening with the prompts,
> after the output from ls.  Hope this is usefull information to help locate
> the problem!!!

Yes, it is. We know now for sure, that your remote machine is innocent,
because it also happens with my local machine, which is known to accept
Tramp requests uncomplainingly. I have disabled your account; we don't
need it anymore.

At work, I have hijacked an old Windows XP machine, for further
tests. Here I could see the same effect as you have seen: Starting a
local shell in Emacs, applying plink to a remote (RHEL5 machine), double

Well, surprising.

Well, not surprising. Let's check. In the Emacs shell buffer, we have
the following process coding system, which is the default for Emacs
running on MS-Windows:

(undecided-dos . iso-latin-1-dos)

That means, both sent and received strings will be coded with
"\r\n". Consequently, the remote host sees a double end-of-line after
each command, which results in returning two prompts. That's why both
you and I see the same in the Emacs shell.

Tramp knows this problem, and tries to solve it. On my Windows XP
machine, it changes the process coding system to

(undecided-dos . iso-latin-1-unix)

This means, it still decodes incoming strings with "\r\n", which does
not hurt. But it encodes strings sent to the remote side just with "\n",
which is correct for Linux machines.

Unfortunately, this happens later during the initialization, and Tramp
hangs already for you. I don't know why it works sometimes (as for the
machine I have in use). Maybe it is a race condition, that the second
prompt does not arrive Tramp in time.

I will work on this, and see whether the hand shaking can be improved.
Process coding systems shall be adjusted as early as possible.

> Gérald

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]