http://www.perlmonks.org?node_id=1076260

taigu has asked for the wisdom of the Perl Monks concerning the following question:

tl;dr;

This...

$telnet->print("65$datastring" . "AO1|AA$password");

...causes some weird box character to precede each print command to a telnet server. Any ideas how it's getting there?

Detail...

So I'm sending commands to a telnet server (it's Standard Interchange Protocol Version 2...used by public libraries to standardize queries across multiple database flavors). All is well and it is working save for one minor detail - all of my print statements to the telnet object are getting preceded by that annoying box character - the kind that you'd see, for instance, if you tried pasting Thai or Chinese into a textbox expecting English. I have no idea how it's getting there, whether it is an encoding issue, etc. The print lines are pretty simple. See above.

Any ideas?

Replies are listed 'Best First'.
Re: Probably easy, but I'm stumped - telnet question
by VinsWorldcom (Prior) on Feb 26, 2014 at 15:55 UTC

    Assuming you're using Net::Telnet, try the 'dump_log' method as it will show the ASCII / Hex of those strange box characters. It may help determine where they're coming from if you know what they are.

    $telnet->dump_log($filename);

    From 'perldoc Net::Telnet':

    dump_log - log all I/O in dump format $fh = $obj->dump_log; $fh = $obj->dump_log($fh); $fh = $obj->dump_log($filename); This method starts or stops dump format logging of all the object's input and output. The dump format shows the blocks read and written in a hexadecimal and printable character format. This method is useful when debugging, ...
      Thanks! Tried input_log and dump_log. Alas, the characters don't show up in either. :-/
Re: Probably easy, but I'm stumped - telnet question
by Corion (Patriarch) on Feb 26, 2014 at 15:09 UTC

    Are you sending carriage returns and newlines where Net::Telnet (resp. the other side) does only expect a newline? Maybe you are on Windows and the author did not binmode the socket handle?

      It does need both. And I'm on Windows. Do you mean the author (as in me) or the author of the telnet server I'm trying to connect to?
        FYI - both the server and client are on Windows.
Re: Probably easy, but I'm stumped - telnet question
by kschwab (Vicar) on Feb 26, 2014 at 19:17 UTC
    Do $datastring and/or $password maybe contain:
    • A character with ASCII value 255? That's the telnet IAC character...if you pass it to $telnet->print(), Net::Telnet will escape it with an extra IAC character. If the other end isn't actually doing the telnet protocol, it won't strip out the extra character.
    • A carriage return that is NOT followed by a newline? Net::Telnet will add a NULL char (ASCII 0) after the carriage return

    In short, if the other end isn't really speaking true "telnet", it can cause this sort of thing.

    You could try $telnet->telnetmode(0); ... that turns this behavior off, making it more like a plain socket.

      Interesting. I'll give telenetmode a go. But no, those scalars wouldn't have an ASCII 255 value.

      Doesn't print automatically add a newline character? What might be happening is that I'm using $telnet->get; to retrieve my responses. That wacky character shows up in my server log when I send a print command - but only following a get command. Perhaps 'get' has something to do with it?

        If the host you are connecting to runs a shell that does "fancy" stuff with the command-line prompt - such as escape strings to set color, bold, reverse-video or whatever in the "terminal" font display - you might be getting residue from that… (but I'm whistling in the dark here).
Re: Probably easy, but I'm stumped - telnet question
by Jim (Curate) on Feb 26, 2014 at 19:03 UTC

    This is pure conjecture by someone who's never written a Perl script to send commands to a telnet server:  Could the "weird box characters" be Unicode byte order marks? What character encoding is the text (presumed to be) in? If, indeed, the unwanted characters are Unicode BOMs, then this might explain why they seem to disappear in your logs, which they should do in any modern text editor.

      Thanks for your reply Jim. A lot of me is leaning in the direction of character encoding. I'll play around with that a bit.