mIRC Homepage

/msg on dashed nicks

Posted By: Sephiroth_

/msg on dashed nicks - 15/04/19 04:08 PM

Hiho,

since 7.53 (or higher) /msg doesn't work for Nicks starting with a dash (bouncers for example), it just returns insufficient parameters error.

Code:
/!msg -sBNC Message => * /msg: insufficient parameters
/!say works => > works
/!me works fine too. => * me works fine too.
/!describe -sBNC works too => * me works too
/!notice -sBNC Message => -> --sBNC- Message


Just updated from 7.52 to 7.55. Not sure which version it startet, but it worked fine on 7.52.

It also works fine, when entering the text at the Querys Editbox.

It appears like it is because of the changes on 7.53 #23, line splitting.

Greetings.
Posted By: maroon

Re: /msg on dashed nicks - 15/04/19 08:51 PM

Another workaround may be 7.53's changelog:

20.Added /privmsg command.
Posted By: Raccoon

Re: /msg on dashed nicks - 16/04/19 01:38 AM

mIRC now anticipates the presence of command switches for /msg. Command switches begin with a dash.

The work-around is simple, though. Use a blank command switch.

/msg - -FooBar Hello -Foobar, you have an invalid nickname!
Posted By: Protopia

Re: /msg on dashed nicks - 16/04/19 09:09 AM

This is an issue of backwards compatibility.

I am unclear why it ever worked in 7.52 if /msg had switches in that release.

I am unclear whether use of e.g. "/msg $nick message" works when $nick is e.g. -sBNC. It may be that mIRC can already or can be made to substitute for standard identifiers that are known to contain nicknames after handling switches, but substitute everything else before i.e. "/msg %switches $nick message" works whether %switches is empty or not and regardless of whether $nick starts with a -.

The issue here is that there are hundreds of scripts which use /msg and expect to continue work with all valid user names even those starting with -.
Posted By: maroon

Re: /msg on dashed nicks - 16/04/19 09:33 AM

The other question is what switches are being recognized, as none are documented. I did see that "/msg -n #channelname message" minimizes the channel along with sending the message.
Posted By: Khaled

Re: /msg on dashed nicks - 16/04/19 09:59 AM

Thanks for your bug report.

mIRC has supported a /msg -s switch since v3.9 but only if it was exactly "-s". Awful design decision. But someone requested -s support and I am guessing we were worried that adding -switch support would result in the issue currently being reported.

The /msg routine is also used by /query to send a message and/or open a window. /query supports combinations of switches -nxmd. Prior to 7.52, it supported only -n.

When I was updating /msg and /query in v7.52, I must have decided to merge support for these switches together for consistency and predictability, which has caused the current issue.

I will revert these changes in the next version. This means that /msg will go back to working how it did before: -s will still be a switch but any other "-" prefixed word will be treated as a nickname. This also means that /query will no longer support -s.

In retrospect, I should have made all /commands treat "-" as a switch if it was the first parameter, even if they did not support any switches, to make behaviour predictable. As this was not done, extending non-switch commands with new switches/features without breaking scripts just leads to issues like this one.
Posted By: Khaled

Re: /msg on dashed nicks - 16/04/19 01:47 PM

Quote:
I did see that "/msg -n #channelname message" minimizes the channel along with sending the message.

If I make the changes suggested in my above post, this will no longer work in the next beta. Any scripts that use /msg -n will break since -n will be treated as a nickname.

On the other hand, I could make it work by supporting switches -snxmd only if combinations of those letters are used. If any other letters are used, the parameter would be treated as a nickname.

Either way, a compromise has to made - either to support the new switches or to unsupport them and revert to pre-v7.52 compatibility - including the support for -s, which would still be an issue for scripts.

Basically, there is no good solution to this. We need to pick the least worst option.
Posted By: Raccoon

Re: /msg on dashed nicks - 16/04/19 02:50 PM

Originally Posted By: Protopia
The issue here is that there are hundreds of scripts which use /msg and expect to continue work with all valid user names even those starting with -.

Nicknames beginning with '-' are not valid nicknames, and never will be, for this very reason. mIRC can't be expected to always work with shotty BNC implimentations that don't conform to IRC specification. IRC specification states that nicknames shalt not begin with a hyphen.
Posted By: Khaled

Re: /msg on dashed nicks - 16/04/19 03:16 PM

Quote:
Nicknames beginning with '-' are not valid nicknames

Good point. I am guessing that BNCs use non-valid nicknames so that they don't collide with nicknames on the IRC server. So the issue with /msg and -switches support will likely only be an issue with users who use certain BNCs. Does that make sense?

Also, /describe and /notice work in the above case only because no one has ever asked for a -switchable feature for them. If someone did, and it was added, they would have the same issue.
Posted By: Sat

Re: /msg on dashed nicks - 16/04/19 05:13 PM

Originally Posted By: Khaled
So the issue with /msg and -switches support will likely only be an issue with users who use certain BNCs.

Right now, yes. I don't necessarily agree with Raccoon's "never will be", though. After all, at some point in the past, IRCnet decided that nicknames could start with a digit after all. Similar messed-up decisions may be taken by IRC networks in the future.
Posted By: Wims

Re: /msg on dashed nicks - 16/04/19 05:50 PM

But this issue with /msg is part of a bigger picture, for /msg it's ok, there are others commands to send a message. The problem is building script around $nick and such. An update of IRC to allow for nickname starting with a number would lead to scripts breaking, stuff like $nick() takes a nickname or a number for the same parameter.
I've written thousand of quick 'nick registration/login' systems for picture games in mIRC, where you don't rely on $me but on something entered by the user via $input or something, if you are not aware of this problem and validate a nick such as 0nick, you'll get in troubles, easily.
To me, the script language relies on nickname not starting with digit and not starting with a dash, so with that in mind and for consistency, "/msg -nick message" should be interpreted as switches and return an error.
Posted By: Khaled

Re: /msg on dashed nicks - 17/04/19 12:48 PM

Quote:
Right now, yes.

Well, the IRC protocol is all we have to work with. It would be impossible to implement an IRC client in a way that supports an unknown future protocol with unknown changes.

The support for /msg and /query -snxmd the way it is currently implemented is the ideal method.

One alternative, where any combination of the letters -snxmd is treated as a switch, and any -otherletters are treated as a nickname, is unpredictable and would make the situation worse. It would allow 120 possible combinations (which would increase if new switches were added) of -snxmd that would not be treated as nicknames.

Another alternative, to revert to pre-7.52 behaviours, and remove support for these switches, would return the behaviours to how they were, with /msg -s and /query -s/-n being supported. This still has the issue in that "-s" and "-n" are special letter combinations that are not treated as nicknames.

Since this issue only seems to affect users who /msg non-valid nicknames, specifically BNCs, we could accept breaking backwards compatibility and require that BNC scripts be updated.
Posted By: Sat

Re: /msg on dashed nicks - 17/04/19 04:44 PM

Originally Posted By: Khaled
Well, the IRC protocol is all we have to work with. It would be impossible to implement an IRC client in a way that supports an unknown future protocol with unknown changes.

Agreed. However, it is an argument in favor of exactly the approach you favor as well, namely to be as consistent as possible, so that scripts can deal with such a new situation in a well-defined way as well (eg by using "/msg - $nick message" everywhere).

However, I think there is one last option that should be mentioned just as a possibility. There are very few such nicknames used by BNC software. I can think of "-psyBNC" and "-sBNC" only; maybe there's a handful in total. mIRC *could* treat *just* those cases as nicknames, as whitelisted exceptions. Then, assuming all those names contain "BNC", perhaps the "-B" switch (or so) could be reserved as never-to-be-added for those commands, so as to prevent that a valid combination of switches ever ends up forming one of those whitelisted exceptions.
Posted By: Raccoon

Re: /msg on dashed nicks - 18/04/19 01:43 AM

There are a lot of things possible. I'm happy with mIRC just breaking for invalid nicks, but if Khaled is really bored he could add a check before failing "not enough parameters" if there are 2 params, treating the first param as nickname and the second param as message.

I think it'd boring to mess with this and just call make mIRC break so that BNC software fixes it on their end. SBNC should use asterisk instead of hyphen, like ZNC does.
Posted By: Khaled

Re: /msg on dashed nicks - 18/04/19 10:47 AM

Quote:
However, I think there is one last option that should be mentioned just as a possibility. There are very few such nicknames used by BNC software. I can think of "-psyBNC" and "-sBNC" only; maybe there's a handful in total. mIRC *could* treat *just* those cases as nicknames

You know, I considered this and discounted it as too kludgey. But looking at it again, this might actually be the least worst option in this case. Assuming that "-" is not a valid prefix for nicknames, and that only a handful of BNCs use invalid -nicknames, we could just whitelist them. This would enable backwards compatibility for existing scripts but would force new scripts that try to use different invalid -nicknames, which is unlikely anyway, to use the -switch prefix.
Posted By: Protopia

Re: /msg on dashed nicks - 18/04/19 07:20 PM

Hmm - it appears from a simple test (on DALnet - other networks may be different) that you cannot have a user nick that starts with a "-".

/nick -abc
-abc Erroneous Nickname

If this is generally true, then as previously commented, such nicks will be system nicks and an explicit whitelist (which might need to be a combination of network and nick) could be the solution.
Posted By: Protopia

Re: /msg on dashed nicks - 18/04/19 07:25 PM

I think if you are going to have such a whitelist, it probably needs to have an Options UI to allow users to add their local userids.

But we could perhaps have an initial list populated with the known such instances.

(So - now something which affects a small group of users needs a UI. Such is the nature of corner cases.)
Posted By: Khaled

Re: /msg on dashed nicks - 18/04/19 07:36 PM

Quote:
I think if you are going to have such a whitelist, it probably needs to have an Options UI to allow users to add their local userids.

This is an internal backwards compatibility fix, not a feature :-] No plans to add a GUI for this.
Posted By: Sat

Re: /msg on dashed nicks - 18/04/19 07:43 PM

Originally Posted By: Protopia
Hmm - it appears from a simple test (on DALnet - other networks may be different) that you cannot have a user nick that starts with a "-".

You might want to take a look at the rest of this thread.
Posted By: Sat

Re: /msg on dashed nicks - 18/04/19 07:49 PM

Originally Posted By: Raccoon
[..] add a check before failing "not enough parameters" if there are 2 params, treating the first param as nickname and the second param as message.

Just for completeness: this does not work nearly as well as all the other proposed solutions, because for at least shroudBNC, not all commands consist of only one word.
Posted By: Protopia

Re: /msg on dashed nicks - 18/04/19 07:57 PM

I said it needs one, not that it was going to get one. wink
© 2019 mIRC Discussion Forums