soul,

The responses above have addressed the problem you're currently asking about, but there's something else that you should know about using Net::Telnet to communicate with Windows Telnet servers, something that appears in the documentation of the Net::Telnet module, and that should definitely be taken on board, as it can lead to a whole world of hurt.

Connecting to a Remote MS-Windows Machine

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 MS-Windows.

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.

This doesn't necessarily mean that you won't be able to achieve the results that you want, but it is definitely something of which to be aware, as the responses that you get from the telnet server might seem very odd indeed...