[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Bug reports
. . -> [Subject]  Basic telnet/terminal protocol bugs in mushclient 3.26
Basic telnet/terminal protocol bugs in mushclient 3.26

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Posted by Orange   United Kingdom  (25 posts)  [Biography] bio
Date Sat 21 Sep 2002 07:12 PM (UTC)
Message
The telnet spec specifies that "IAC IAC" should be treated
as whatever char IAC happens to be (in ISO-8859-1 this is ÿ or y-with-umlaut), not two of them, or zero of them.

By ANSI, CSI (or 0x9b) should be treated as equivilant to ESC[

Finally, ESC[22m should turn bold off, it isn't doing.
[Go to top] top
Posted by Orange   United Kingdom  (25 posts)  [Biography] bio
Date Reply #1 on Sat 21 Sep 2002 07:23 PM (UTC)
Message
D'oh. And now I notice you've already got a bug open for turning bold-off. Didn't think it'd be in the 'suggestions' bit. My apologies.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #2 on Sat 21 Sep 2002 08:33 PM (UTC)

Amended on Sat 21 Sep 2002 08:36 PM (UTC) by Shadowfyr

Message
>By ANSI, CSI (or 0x9b) should be treated as equivilant to ESC[

Maybe a good idea 'if' you are not using a mud that uses foreign languages or your client strips the list bit off. It may even be useful to bypass the restriction some muds place on imbedded escape sequences. However the reason whatever you are reading says 0x9b is is equivalent to esc[ is because 155 - 128(hi-bit) = 27 (esc). This is, and has in the past, even in old dialup BBS software, been true only for clients that do not recognized characters over 0x7f. In general, on any client that supported what you suggest, any character between 0x80 and 0xa1 are treated as command codes and ignored by the client as though they where the equivalent (char - 128) command code. This is probably not a good idea, and it is even worse when you consider that the Terminal font that 'used' to be the standard and still is in the PC hardware, as well as some other fonts, treat that character and others as something completely different than the 'current' standard. In the case of Terminal, it is a c with a line through it (i.e. the cent symbol). The old DOS spec for 7-bit ANSI that your equivalency comes from is really no longer a viable standard and hasn't been for quite some time.
[Go to top] top
Posted by Orange   United Kingdom  (25 posts)  [Biography] bio
Date Reply #3 on Sat 21 Sep 2002 09:49 PM (UTC)
Message
But if mushclient is interpreting the input from the mud as ISO-8859-1 (which it certainly seems to), there's no reason not to obey the C1 control characters which are well defined.

And just to clarify 0x9b in an ANSI stream is equivilant to the actual byte sequence 0x1b 0x5d NOT 0x1b, as you seem to think I'm saying. See section 8.3.16 of ECMA-048.

Sure, if it was using CP437 or CP850 or some other abomination, it'd want to do those right.

By the way, my mud supports foreign languages just fine thank-you, it can be configured to output stuff in Latin1/MacRoman/etc or even UTF-8 as the client demands.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #4 on Sun 22 Sep 2002 01:41 AM (UTC)
Message
Ok. So I could am wrong. :p

I still think using a single character to represent any sequence of them is just plain stupid. It isn't something you need to do at any existing badwidth (maybe back when we had 300 baud modems..) and you end up having to add cludge code to handle the 'what if it isn't meant to be 0x1b 0x5d in this instance?' situations. Imho it only makes life more difficult for the program developers to support something that 90% of the people designing the server end will never find it necessary to use. I am also fairly sure that ansi under DOS and probably most other text based systems never did support that part of the spec.

I can say that in over 15 years of using computers and writing code, I have never seen that part of the ansi spec used anywhere, so I am not sure why everyone would suddenly decide to start supporting it.

In any case I freely admit to not being an expert on every tech doc in existance or even a few of them for that matter. lol
[Go to top] top
Posted by Nick Gammon   Australia  (22,990 posts)  [Biography] bio   Forum Administrator
Date Reply #5 on Sun 22 Sep 2002 06:44 AM (UTC)

Amended on Sun 22 Sep 2002 06:46 AM (UTC) by Nick Gammon

Message
Version 3.27 supports IAC IAC as a single IAC, and also the following ANSI codes:

21: cancel bold
24: cancel underline
25: cancel italic
27: cancel inverse

Quote:

And just to clarify 0x9b in an ANSI stream is equivilant to the actual byte sequence 0x1b 0x5d NOT 0x1b, as you seem to think I'm saying. See section 8.3.16 of ECMA-048.


I'm not too sure about this, and in any case I haven't heard of any MUD that requires it. If it did treat 0x9b as 0x1b 0x5b surely that makes the character 0x9b unavailable?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Orange   United Kingdom  (25 posts)  [Biography] bio
Date Reply #6 on Sun 22 Sep 2002 08:40 AM (UTC)
Message
Well, doesn't the client need to know what encoding the mud is using in order to convert the input line before sending? If so, and it's a sensible encoding that doesn't trample all over the C1 area, Bob's your uncle.

(Checks if that's the case. Oh, it seems not. If i choose a cp437 font [terminal], and then connect to a mud, although the output from the mud is properly displayed as cp437, input to the mud is still sent as Latin1!

Sure, there's an option to change the font in the input line, but if I do that and type £ (pound), uacute appears in the actual box.

Eep.)
[Go to top] top
Posted by Nick Gammon   Australia  (22,990 posts)  [Biography] bio   Forum Administrator
Date Reply #7 on Sun 22 Sep 2002 10:50 AM (UTC)
Message
Quote:

Well, doesn't the client need to know what encoding the mud is using in order to convert the input line before sending?


How would it know that? I have never heard of a MUD doing that. I am not saying it isn't done, and if you can point me to the appropriate documentation I'll take a look.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Orange   United Kingdom  (25 posts)  [Biography] bio
Date Reply #8 on Sun 22 Sep 2002 11:51 AM (UTC)
Message
Well, RFC 2066 specifies the telnet charset option, (which I've not seen implemented anywhere). But as demonstrated above (my pressing '£' and getting 'ú'), in the absence of any negotiation, there ought to be a client option for what charset the server's using, and conversion be done. Given that, its easy to tell whether 0x9b is a printable char or CSI. And if it isn't there, then muds that aren't running in Latin1 aren't supported properly anyway...
[Go to top] top
Posted by Orange   United Kingdom  (25 posts)  [Biography] bio
Date Reply #9 on Mon 23 Sep 2002 12:30 PM (UTC)
Message
Oh, and it's 22 to cancel bold, not 21 (which means to turn double underline on).
[Go to top] top
Posted by Nick Gammon   Australia  (22,990 posts)  [Biography] bio   Forum Administrator
Date Reply #10 on Mon 23 Sep 2002 08:47 PM (UTC)
Message
Can you give me the RFC number where this is documented? I am working off an earlier report, at Unbold, unblink, unreverse wanted where 21 and 22 are listed as un-bold and un-half-intensity, I may as well get it right.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Orange   United Kingdom  (25 posts)  [Biography] bio
Date Reply #11 on Mon 23 Sep 2002 09:56 PM (UTC)
Message
Try ECMA 48 available at ftp://ftp.ecma.ch/ecma-st/Ecma-048.pdf

Section 8.3.117 (page 75 in the PDF, 61 by the numbering) specifies SGR (ie CSI...m).

I believe early versions of the Linux console mistakenly used 21 to indicate bold-off, this may be the source of the error.
[Go to top] top
Posted by Nick Gammon   Australia  (22,990 posts)  [Biography] bio   Forum Administrator
Date Reply #12 on Tue 24 Sep 2002 03:53 AM (UTC)
Message
Hmm - I see what you mean.

Version 3.27 now supports the following ANSI codes:

3: italic
5: slow blink (currently represented as italic)
6: fast blink (currently represented as italic)
22: cancel bold
23: cancel italic
24: cancel underline
25: cancel blink (currently represented as italic)
27: cancel inverse
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

28,633 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]

Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]