tags:

views:

48

answers:

3

This is strange enough I'm not sure how to search for an answer. I have a program in Python that communicates via TCP/IP sockets to a telnet-based server. If I telnet in manually and type commands like this:

SET MDI G0 X0 Y0

the server will spit back a line like this:

SET MDI ACK

Pretty standard stuff. Here's the weird part. If, in my code, I precede my printing of each of these lines with some text, the returned line erases what I'm trying to print before it. So for example, if I write the code so it should look like this:

SENT: SET MDI G0 X0 Y0
READ: SET MDI ACK

What I get instead is:

SENT: SET MDI G0 X0 Y0
SET MDI ACK

Now, if I make the "READ: " text a bit longer, I can get a better idea of what's happening. Let's say I change READ: to 12345678901234567890, so that it should read as:

12345678901234567890: SET MDI ACK

What I get instead is:

SET MDI ACK234567890:

So it seems like whatever text I'm getting back from the server is somehow deleting what I'm trying to precede it with. I tried saving all of my saved lines in a list, and then printing them out at the end, but it does exactly the same thing.

Any ideas on what's going on, or even on how to debug this? Is there a way to get Python to show me any hidden chars in a string, for example?

thx!

+1  A: 

It is likely your telnet program is expecting CR-LF delineated new lines, and Python is doing on LF or CR feeds.

Yann Ramin
+2  A: 

You probably have a stray carriage return without a newline. Try using raw strings in Python instead to see what's up.

John Feminella
thanks, this got me more info. initially the server is sending lines like this:SET MDI ACK\r\nas expected. But then sometimes I'm getting:\rSET MDI ACK\nWhen it does this I get the strange behavior. Not sure what to do about it yet, but at least I don't feel insane!!
mix
+3  A: 

If you print repr(send) and repr(received) instead of just printing sent and received, you'll have a much clearer idea about exactly what you're sending and what you're getting back in return (so you can check if @theatrus' suggestion is correct, etc, etc, and at all times clearly see what you're doing).

This is close to one of my favorite pragmatical principles: whenever printing or logging a string that might possibly be in error, always print its repr (or %r instead of %s, if that's how you're doing the formatting), never just the plain string itself (or its %s, which does nothing to it).

Over and over again, if you don't use the repr, you'll waste substantial amounts of time debugging problems that you can't really see because the characters that snuck into the string by mistake and are therefore causing said problems aren't showing clearly in the logs (non-printing characters, control characters, and so on).

So, always use repr to display or log strings unless you're 100% certain that they are perfectly correct and predictable -- get into the habit, it isn't any harder than not doing it once you are in the habit, and over the years you will have many occasions to thank this little, simple principle.

Alex Martelli