Is the FluffOS efun::terminal_colour() returning odd bits?

[Hilapdatus]

I'm too lazy to fire up a Dead Souls instance or test different drivers so I'm wondering if somebody could do me a favor... 

Our mud has a strip_colours(string str) sefun that calls TERMINAL_D->no_colours(str).  no_colours(string str) calls efun::terminal_colours(str, m) where m is a mapping that associates PinkFish codes with some sort of string to provide colour for a given terminal type, most often these are ANSI Escape sequences but in this instance the mapping associates each PinkFish code with a blank string.

My dilemma is that it is behaving oddly and our mudlib looks okay to my eyes so I'm thinking it is the driver.

In the first case, all is good.  The PinkFish codes are removed and the length of the resultant string, "asdf", is 4.  Normal and boring.

    > eval return strlen(strip_colours("%^BOLD%^%^YELLOW%^asdf%^BOLD%^"))
    Result = 4

If we change the last PinkFish code to a %^RESET%^, however, the length of the resultant string goes all screwy.

    > eval return strlen(strip_colours("%^BOLD%^%^YELLOW%^asdf%^RESET%^"))
    Result = 19
    > eval return strlen(strip_colours("asdf%^RESET%^"))
    Result = 19
    > eval return strlen(strip_colours("%^RESET%^")
    Result = 15

That final %^RESET%^ should be replaced with a blank string but it is getting replaced with I don't know what but whatever it is it's 15 characters long.  Does DS have the same/similar code and does it behave the same as well?

I am working on Dreamverse which is a modified Nightmare IV mudlib running on FluffOS v3.0-alpha7.4.

Thank you!
Hil

[Hilapdatus]

I tried to be a little less lazy and fired up tcpdump to take a look.  The 15 character sequence is an ANSI sequence:

    ^[49;49m^[0;10m

From http://en.wikipedia.org/wiki/ANSI_escape_code, it looks like that sequence is meant to reset/disable all ANSI attributes even though the mapping passed to terminal_colour() says to replace %^RESET%^ with an empty string.

A typical %^RESET%^ for an ansi-capable terminal is replaced with ^[0m and not all the junk above.

Does this look like a driver bug?  What am I missing?

[quixadhal]

Code: [Select]

> eval string x = "%^BOLD%^%^YELLOW%^asdf%^RESET%^"; string y = strip_colours(x); int z = strlen(x); int zz = strlen(y); return ({ z, zz });
Result = ({ 31, 19 })

> eval string x = "%^BOLD%^%^YELLOW%^asdf%^RED%^"; string y = strip_colours(x); int z = strlen(x); int zz = strlen(y); return ({ z, zz });
Result = ({ 29, 4 })


Interesting.

Code: [Select]

> eval string x = "%^BOLD%^%^YELLOW%^asdf%^RESET%^"; string y = strip_colours(x); int z = strlen(y); int i; for( i = 0; i < z; i++ ) { write(sprintf("%02d %02x", i, y[i])); }

00 61
01 73
02 64
03 66
04 1b
05 5b
06 34
07 39
08 3b
09 34
10 39
11 6d
12 1b
13 5b
14 30
15 3b
16 31
17 30
18 6d
Result = 0

Now, are you ready to be terrified?  Here's a horrible thing that seems to be the result of LPC's type-by-value rather than type-by-variable...

Code: [Select]

> eval string x = "%^BOLD%^%^YELLOW%^asdf%^RESET%^"; string y = strip_colours(x); int z = strlen(y); int i; for( i = 0; i < z; i++ ) { write(sprintf("%02d %c", i, y[i])); }

00 a
01 s
02 d
03 f
04 [0m
05 [
06 4
07 9
08 ;
09 4
10 9
11 m
12 [0m
13 [
14 0
15 ;
16 1
17 0
18 m
Result = 0

Note that I'm using sprintf's %c token to see the individual character values.... but in cases where the value is an ESC, sprintf's %c ends up seeing the rest of that string!

Oddly enough, this explains a strange phenomenon in my i3 logs.  For ages now, I've been trying to figure out where the weird escape sequence of ESC[49;49m was coming from.  I couldn't ever find it in the source of anything, but it shows up in EMOTE strings over I3.

Wodan?  Cratylus?  Any ideas about this?  I'm at a loss, since while I'm using Dead Souls, I'm also using a customized color system.  The odds of this hitting both me AND someone using Nightmare IV are pretty slim, unless it's a bug introduced in the driver's terminal_color() changes, or a very LONG standing bug from the dark ages that's in EVERY nightmare based mudlib out there...

[quixadhal]

Heh, even more interesting and amusing... I fired up the old Discworld mudlib under a newer FluffOS driver.

Code: [Select]

> exec string x = "%^BOLD%^%^YELLOW%^asdf%^RESET%^"; string y = strip_colours(x); int z = strlen(y); int i; for( i = 0; i < z; i++ ) { write(sprintf("%02d %c\n", i, y[i])); }; return y;

00 U
01 S
02 E
03 R
04 _
05 B
06 O
07 L
08 D
09 U
10 S
11 E
12 R
13 _
14 Y
15 E
16 L
17 L
18 O
19 W
20 a
21 s
22 d
23 f
24 U
25 S
26 E
27 R
28 _
29 R
30 E
31 S
32 E
33 T

Returns: "USER_BOLDUSER_YELLOWasdfUSER_RESET"

So, this one seems to attempt to replace the raw pinkfish codes with custom ones... but doesn't actually replace them properly (no delimiters), so instead of the second pass then replacing them with something else, they get left as the raw token names.

I'm not as familiar with the Discworld mudlib, so maybe you have to hand-fiddle with terminal types or something, but as it stands, that seems to not work.

[Andrew]

In the terminal_colour() efun (packages/contrib.c) if RESET is a 0 length string or not present in the colour mapping then it gets replaced with the escape code:

Code: [Select]

    if(!resetstrlen) {
        //we really really need one, so just default to ansi reset
        resetstr = "\e[49;49m\e[0;10m";
        resetstrlen = 15;
        add_mapping_string(sp->u.map, "RESET", resetstr);
    }

Andrew

[quixadhal]

Ugh... that's a horrible design decision!

If I want to map something to the empty string, I should be ABLE to map it to the empty string.  This is extra bad if you're writing support for a terminal that won't handle ANSI sequences at all, in which case this adds extra screen noise.

Thanks for tracking that down!  If it won't be officially changed, I'll make it a local edit to my own copy from now on.