nobody at nowhere.com
Fri Aug 6 23:41:56 CEST 2004
I found the answer... but not the solution. The problem comes from the fact
that Microsoft does not use a *real* telnet server. It's documented in Perl
Net::Telnet doc. They are not fully respecting telnet protocol. Windows
Telnet Server resend the text and ANSI char that would appear in a cmd.exe
window. Curious? Sure! So each time you send a command from a client that
lead to "push" the previous command out of the vitual "display" space,
Windows Telnet Server resend all the resulting "display". You can try it
with a Windows telnet session where the client is started from cmd.exe.
You'll see that after login (here though!), you can write 7 "echo" commands
and get the reply without "pushing" previous "echo" out of the window. On
the 8th "echo" ("echo bar7" in the script given in this thread), the window
is redraw. And when programmaticaly telneting this kink of server, you get
ALL what the screen would contain if it were a cmd.exe window. Yes! ALL!
Even what you already receive. Making the read_until() function unusable.
Here is what I've fond on Perl Net::Telnet doc:
By default MS-Windows doesn't come with a TELNET server. However third party
TELNET servers are available. Unfortunately many of these servers falsely
claim to be a TELNET server. This is especially true of the so-called
"Microsoft Telnet Server" that comes installed with some newer versions
When a TELNET server first accepts a connection, it must use the ASCII
control characters carriage-return and line-feed to start a new line (see
RFC854). A server like the "Microsoft Telnet Server" that doesn't do this,
isn't a TELNET server. These servers send ANSI terminal escape sequences to
position to a column on a subsequent line and to even position while writing
characters that are adjacent to each other. Worse, when sending output these
servers resend previously sent command output in a misguided attempt to
display an entire terminal screen.
Connecting Net::Telnet to one of these false TELNET servers makes your job
of parsing command output very difficult. It's better to replace a false
TELNET server with a real TELNET server. The better TELNET servers for
MS-Windows allow you to avoid the ANSI escapes by turning off something some
of them call console mode.
Hope it will prevent anybody to spent as much time as I did on this problem!
More information about the Python-list