This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

Backspace character not properly handled?

Posted by Larkin on Wed 20 Jul 2005 10:54 AM — 15 posts, 64,519 views.

Larkin #0
I noticed while playing Lusternia (though the same happens on any IRE game) that when I use my third eye defense and look at the who list I get strange, unprintable characters. When using the third eye and looking at WHO, you see two columns instead of one. The first column is a person's name with full title, and the second is their current location. Some people have really long titles, and it seems that Lusternia's solution to this situation is to send backspaces before the location is sent. Here's the packet debug I captured, and where you see the 08 characters (backspace) is where I see the unprintable characters in my display.

Incoming packet: 12 (770 bytes)

.(The Moonhart M   08 28 54 68 65 20 4d 6f 6f 6e 68 61 72 74 20 4d
other Tree)..Lan   6f 74 68 65 72 20 54 72 65 65 29 0d 0a 4c 61 6e
ista Malicia La'   69 73 74 61 20 4d 61 6c 69 63 69 61 20 4c 61 27
Saet, Sunaj Blad   53 61 65 74 2c 20 53 75 6e 61 6a 20 42 6c 61 64
e    (The Moonha   65 20 20 20 20 28 54 68 65 20 4d 6f 6f 6e 68 61
rt Mother Tree).   72 74 20 4d 6f 74 68 65 72 20 54 72 65 65 29 0d
.Squire of the A   0a 53 71 75 69 72 65 20 6f 66 20 74 68 65 20 41
rmies of Light,    72 6d 69 65 73 20 6f 66 20 4c 69 67 68 74 2c 20
Sharissa Tharedi   53 68 61 72 69 73 73 61 20 54 68 61 72 65 64 69
a........(Lower    61 08 08 08 08 08 08 08 08 28 4c 6f 77 65 72 20
Syrinx street in   53 79 72 69 6e 78 20 73 74 72 65 65 74 20 69 6e
 the artisa)..At   20 74 68 65 20 61 72 74 69 73 61 29 0d 0a 41 74
halas La'Saet      68 61 6c 61 73 20 4c 61 27 53 61 65 74 20 20 20
                   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
      (The Moonh   20 20 20 20 20 20 28 54 68 65 20 4d 6f 6f 6e 68
art Mother Tree)   61 72 74 20 4d 6f 74 68 65 72 20 54 72 65 65 29
..Kariol, Seren    0d 0a 4b 61 72 69 6f 6c 2c 20 53 65 72 65 6e 20
Brave              42 72 61 76 65 20 20 20 20 20 20 20 20 20 20 20
          (The M   20 20 20 20 20 20 20 20 20 20 28 54 68 65 20 4d
oonhart Mother T   6f 6f 6e 68 61 72 74 20 4d 6f 74 68 65 72 20 54
ree)..Evanescent   72 65 65 29 0d 0a 45 76 61 6e 65 73 63 65 6e 74
 Luxis, Student    20 4c 75 78 69 73 2c 20 53 74 75 64 65 6e 74 20
of the Nine   (T   6f 66 20 74 68 65 20 4e 69 6e 65 20 20 20 28 54
he Pool of Stars   68 65 20 50 6f 6f 6c 20 6f 66 20 53 74 61 72 73
)..Rhau, Seren B   29 0d 0a 52 68 61 75 2c 20 53 65 72 65 6e 20 42
rave               72 61 76 65 20 20 20 20 20 20 20 20 20 20 20 20
           (Alab   20 20 20 20 20 20 20 20 20 20 20 28 41 6c 61 62
aster Road)..Dru   61 73 74 65 72 20 52 6f 61 64 29 0d 0a 44 72 75
id Rihver, of th   69 64 20 52 69 68 76 65 72 2c 20 6f 66 20 74 68
e Wilde            65 20 57 69 6c 64 65 20 20 20 20 20 20 20 20 20
     (The Moonha   20 20 20 20 20 28 54 68 65 20 4d 6f 6f 6e 68 61
rt Mother Tree).   72 74 20 4d 6f 74 68 65 72 20 54 72 65 65 29 0d
.Torak, Scourge    0a 54 6f 72 61 6b 2c 20 53 63 6f 75 72 67 65 20
of the Damned      6f 66 20 74 68 65 20 44 61 6d 6e 65 64 20 20 20
         (Centre   20 20 20 20 20 20 20 20 20 28 43 65 6e 74 72 65
 of the Necropol   20 6f 66 20 74 68 65 20 4e 65 63 72 6f 70 6f 6c
is)..Daganev d'I   69 73 29 0d 0a 44 61 67 61 6e 65 76 20 64 27 49
asani Treeripper   61 73 61 6e 69 20 54 72 65 65 72 69 70 70 65 72
, the Merciless.   2c 20 74 68 65 20 4d 65 72 63 69 6c 65 73 73 08
.(Before the Mas   08 28 42 65 66 6f 72 65 20 74 68 65 20 4d 61 73
ter Ravenwood Tr   74 65 72 20 52 61 76 65 6e 77 6f 6f 64 20 54 72
ee)...[32m4418h,   65 65 29 0d 0a 1b 5b 33 32 6d 34 34 31 38 68 2c
.[37m.[32m 2471m   1b 5b 33 37 6d 1b 5b 33 32 6d 20 32 34 37 31 6d
,.[37m.[32m 3140   2c 1b 5b 33 37 6d 1b 5b 33 32 6d 20 33 31 34 30
e,.[37m.[32m 10p   65 2c 1b 5b 33 37 6d 1b 5b 33 32 6d 20 31 30 70
,.[37m.[32m 2099   2c 1b 5b 33 37 6d 1b 5b 33 32 6d 20 32 30 39 39
0en,.[37m.[32m 1   30 65 6e 2c 1b 5b 33 37 6d 1b 5b 33 32 6d 20 31
1405w.[37m elrx-   31 34 30 35 77 1b 5b 33 37 6d 20 65 6c 72 78 2d
..                 ff f9
Zeno USA #1
I don't think MC supports backspaces because it's just a little odd for a MUD to use the character.
See:
http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=4283
Larkin #2
Something being 'a little odd' is not a reason to omit support for it, in my opinion. These are not small MUDs, either. Handling the backspace may be a strange case, but it should be part of a complete standard. I'm just reporting it because it outputs strange characters and makes triggering anything like this impossible.
David Haley USA #3
Nick has more reasons than just "it's a little odd". Special telnet characters like cursor movement etc. create massive headaches for triggers in general. As a programmer, think a bit about handling triggers when the cursor can jump around willy nilly and characters can disappear whenever the MUD feels like sending a backspace.
Larkin #4
The backspace isn't the same as ANSI cursor movement, in my opinion. There is presumably some amount of pre-processing going on already before triggers are processed, so why not just account for backspacing and delete those extra characters from the buffer?

The problem could possibly be worked around using a plugin with the OnPluginPacketReceived event, but this is something I feel belongs in the core MUSHclient executable.

And, if you wanted to trigger something with backspaces in it, how would you go about it? I honestly want to know if you have a regular expression to match these lines. If I did something like \x08*, would that even work?
David Haley USA #5
I'm not sure why a backspace is really that different from a cursor movement. If you output "abcd" followed by a beginning of line motion and then "efgh", that's effectively the same as "abcd", four backspaces, then "efgh".

Imagine what you would have to do to correctly handle receiving a backspace at any arbitrary location. Imagine that you've just matched a trigger against a line, and the server sends a backspace thus changing that line so that it no longer matches the trigger. How do you "un-match" the trigger? You can't.

Implementing backspaces in the buffer would only work in certain specific circumstances. Don't forget that there is no guarantee on how fragmented the packets will be.

As for writing your triggers, well, you can probably escape it and it should work.

For a MUD to be sending backspaces really is strange, though. If they don't mean to send a character, then they shouldn't send it...
Shadowfyr USA #6
Except, triggers only handle 'if' the line matched 'after' the entire line completes, so it would not match on 'abcd' in the first place, but rather 'only' see the final 'efgh' when the newline arrived. Unless you are using packet checking to do a partial match, its impossible for a conflict to arise. It just means that what ever 'prior' text appeared and got erased is not available, which is perfectly logical given how triggers work in Mushclient. So no, it isn't effectively the same as text positioning. But even if it was, solving it would imply buffering what is recieved prior to the next newline and treating the entire result for a match, instead of only matching on what finally gets displayed. The issue was never exactly about triggers, it was about dealing with the display.

Though, I still don't see where that is as big an issue either. We deal with a lot of limitations already, like not being about to match exact color for anything but the initial character, not having partial line matching, etc. So, making it clear that triggers do not work with animation or adjusting triggers to deal with entire sequences, not just the 'final' line you end on isn't that huge problem. Which really only leaves Nick's objections about how to deal with the display. An issue I don't entirely understand the problem with.
David Haley USA #7
We've been over this before - implement it yourself and see if you can get it right, and then show us how it's done. :-)
Larkin #8
I see your point about the packets being fragmented, and I accept that as a good reason to not delete the characters from the buffer for the purposes of triggering, at least for now. The display thing is annoying me still, however. zMUD handles these characters properly, and I'm sure many other clients do as well, so I'm really wondering what the major difference is here.
Greven Canada #9
I brought this up my self some time ago, and he went in depth about several reasons why he doesn't do it.

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=5114
Shadowfyr USA #10
And as I have said before Ksilyan, there have been implimentations of it, just not in a graphical based context. The only fundimental difference between how something like the old DOS based Telemate handled triggers, buffering and text display, even with positioning implimented, is that 'it' relied on video hardware to handle the display, where Mushlclient relies on a software implimentation. But the basic logic involved is the same. In there case they dealt with it by having the log record 'everything', but the scroll buffer only remember the 'last' state of the line(s), before they scrolled off. Same with clearscreens. Why reinvent the wheel if a perfectly good example of how someone else handled it exists.

As for coding such a thing myself... Knowing the logic for it and actually implimenting it are two different things, especially since I don't know C++ well enough to have a snowballs chance in hell of even getting a window to appear, never mind building the logic for this. Not everyone can code well enough to impliment every idea they want to try, if they could, there would be hundreds of competing telnet clients, not *maybe* a dozen.
Nick Gammon Australia Forum Administrator #11
First thing, I think it is very bizarre for a server to backspace stuff it has sent. Backspacing was intended for humans to correct errors they make when typing. For a program to "correct itself" is very strange. Also, in the case you quote of "very long titles", say the server wants to display a 10-character max title, but the player has a 80-character title, then using its implementation it sends 80 characters of title, followed by 70 backspace characters. Doesn't this seem strange to anyone else?

In C, it is very easy for the programmer to set fixed width strings, and truncate. Eg., using printf:


Print a string: %s

Print a string padded out to 10 characters: %10s

Print a string padded to 10 characters, and truncating extras: %10.10s


Having grumbled about this particular server implementation, we now look at what the client has to do to process backspaces.

The client receives data in packets, not necessarily discrete lines, or even logical parts of a line. For example, an ANSI colour sequence (ESC [ some-number m) might be broken across 2 packets by the network layer.

Thus to work reliably the client maintains a "state machine" where it remembers, for each incoming byte, the current state. For example, when processing MXP (MUD Extension Protocol) the "<" symbol triggers the "MXP element" state, and the < symbol, and text following it, are not displayed in the client window.

Now imagine what would happen if we get "<" followed by backspace. It has to undo the state change, and revert to the previous state, whatever that was. This would be horrendously complex to handle every possible combination.

Having said all that, using the newish OnPluginPacketReceived plugin callback, we can write a small plugin that will handle backspaces at the packet level, before the data hits the state machine. This should work fine for you, providing the incoming data does not have backspaces over a packet boundary. For all I know this will be 99% of the time.


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<!-- Saved on Saturday, July 23, 2005, 11:04 AM -->
<!-- MuClient version 3.66 -->

<!-- Plugin "ProcessBackspaces" generated by Plugin Wizard -->

<muclient>
<plugin
   name="ProcessBackspaces"
   author="Nick Gammon"
   id="c4fef242b44904d009ade8a0"
   language="Lua"
   purpose="Process backspace characters in individual packets"
   date_written="2005-07-23 11:01:38"
   requires="3.59"
   version="1.0"
   >

</plugin>


<!--  Script  -->


<script>
<![CDATA[
function OnPluginPacketReceived (s)

repeat 

  i = string.find (s, "\b") -- find backspace
  
  if i then 
    if i <= 1 then
      s = string.sub (s, 2)  -- just delete the backspace
    elseif i == 2 then
      s = string.sub (s, 3)  -- deleting first character
    else
      s = string.sub (s, 1, i - 2) .. string.sub (s, i + 1)
    end -- if i > 1
  end  -- if backspace found

until not i

return s
  
end -- function OnPluginPacketReceived
]]>
</script>


</muclient>


Just copy the above text, paste it into a text editor, and save as ProcessBackspaces.xml. Then use the plugin menu to add that as a MUSHclient plugin. That should fix your problem. :)
Shadowfyr USA #12
It really not that odd Nick. Think about it for the moment. Most clients do handle backspace, but not the ansi codes for text positioning. Its not entirely uncommon for something like a text cursor, like the following:

$e[s/$e[u|$e[u\$e[u-$e[u\ and so on.

Or alternatively:

/$e[1D|$e[1D\$e[1D-$e[1D/

Both of these create a cursor that was not uncommon on some BBSes, which appears to spin. This is probably the most common instance of doing this sort of thing. However, if you can't use the ansi commands, then you can 'fake' it with backspace, which most clients will support anyway. In fact, backspace is safer, since it is a 'line' based command, so cannot wrap around to the next line, it just stops when it hits the first character. As for the state machine issue. I suspect most clients do use something of the sort, but I could be wrong.
Nick Gammon Australia Forum Administrator #13
I understand that, using a single backspace to replace a single character, to create an animation effect.

However it still seems strange to me to send 30 characters, followed by 20 backspaces, because you are trying to make a 10-character column, and because you are too lazy to simply truncate the data before sending it. It is wasteful. Not only that, but depending on the speed of the connection, and the packet boundaries, you may get flicker as the text is drawn on the screen and then removed.
Shadowfyr USA #14
Well yes.. That is really quite bizzare. lol