Alias labels in perlscript

I know this happens in the perlscript plugin, but I'm not sure about other languages. Also, I'm using MUSHclient 3.19.

When an alias calls a script, the label name (stored in $_[0]) is sent in all-lowercase, regardless of the capitalisation used in the Label editbox for that alias. This does not happen to trigger labels, only alias labels.

Yes, I see what you mean.

Triggers return the exact label you typed, whilst aliases and timers convert them to lower case.

I'm not sure this is, strictly-speaking, a bug, as the behaviour is not really documented.

However one of my other posts said the first argument to triggers, timers and aliases was "the label you entered" so I suppose preserving the capitalisation is correct.

The trouble is, if I change it now, some scripts that rely on the label being in lower-case may fail.

Does anyone else have any comments?

You can use script to change a string to lowercase, but there is no way to "guess" which characters were uppercase in the label name.

I think ya know what ya gotta do. :)

What you are saying is, if I make them the original case you can always make them lowercase, but not the other way around? The problem is, each of the three things I do can cause problems ...

1. Do nothing. Scripts will continue to work as before, however aliases and triggers are not consistent (one is lower case, the other isn't).
2. Change MUSHclient to return the exact case you entered. This is fine, except existing scripts might be testing on the lower-case version (of aliases and timers) and will now stop working (until the script is changed to force them to lower-case).
3. Change MUSHclient to return them all in lower-case. You lose a bit of information, but it saves the script having to do it. It doesn't matter that much, as you can't have two labels which are the same, except for case.

So, which is the best way to go?

Option 2.

This is the most versatile. I've already comment on option 1. Option 3 may cause problems for those who need to set a label which is actually used by the script. To force lowercase, you set a barrier for programmers to work around, which is not necessary.

Regarding your concern, you can make a mention of the change is the release notes. It's not unusual for a newer version of software to require minor updates to user files.

I actually doubt there are many "out there" who would be effected. I use label names myself, but only in triggers, there isn't as much need for specialized labels in aliases.

I'm trying to think of an example where one would be used. perhaps:

Hmm... I actually have those two aliases, but rather that use an IF statement, I simply put "flag %1" in the Send box of the latter, while the former has nothing in the Send box.

In writing that, I realized that if I had wanted that to work, I would have needed to make the IF statement check for "backstab_and_flag". It's probably natural that I would have seen the inconsistency, and changed the label to lowercase as well.

If you make the #2 change, nothing will change for those that already use a lowercase label, it's only the people who use an uppercase label and check for lowercase in their script. I'm betting Moho was the first to notice.

Yeah, the reason I encountered this was that I was using a single function which was called by both triggers and aliases, with similar purposes. To distinguish between the two I labeled one (for example) as "b_Butcher_alias" and one as "b_Butcher_trigger". I noticed the inconsistancy because the alias part just wasn't working (using the case-sensitive 'eq' comparison). So it ended up like this:

if ($label eq "b_Butcher_trigger") { ... }
elsif ($label eq "b_butcher_alias") { ... }

Even though the case of the B was upper in both labels. In actual fact, the function was called by about 6 triggers and 3 aliases, resulting in a weird mix of cases dependant on whether or not a particular if-branch was the result of an alias or trigger call.

Of course, I'd prefer option 2, case preservation.