|
Joined: Mar 2013
Posts: 4
Self-satisified door
|
OP
Self-satisified door
Joined: Mar 2013
Posts: 4 |
I use NBS-IRC along with my MIRC.
But when I try and join a channel, it says: "* Error recursive call (line 71, alias2.nbs)"
This is with the new mirc. It didn't occur before.
Last edited by KyleSmith; 19/06/14 05:57 PM.
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
This is because of the item 47 in the changelog of mIRC 7.33. For years, mIRC was calling the built-in command whenever you are inside the custom alias for that command: alias join { join $1 }
was the same as the now required:
alias join { !join $1 } I wanted to make a report about it too because a lot of scripters took that old behavior for a rule, while nothing ever described it. Practically speaking, mIRC does not support direct recursion, the new behavior is more consistent but the old one was ok too, since we couldn't call the alias again, it somewhat makes sense that we wanted to call the built-in command at this point.
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Mar 2013
Posts: 4
Self-satisified door
|
OP
Self-satisified door
Joined: Mar 2013
Posts: 4 |
This is because of the item 47 in the changelog of mIRC 7.33. For years, mIRC was calling the built-in command whenever you are inside the custom alias for that command: alias join { join $1 }
was the same as the now required:
alias join { !join $1 } I wanted to make a report about it too because a lot of scripters took that old behavior for a rule, while nothing ever described it. Practically speaking, mIRC does not support direct recursion, the new behavior is more consistent but the old one was ok too, since we couldn't call the alias again, it somewhat makes sense that we wanted to call the built-in command at this point. Thank you for that!
|
|
|
|
Joined: Dec 2002
Posts: 5,481
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,481 |
This change was made partially as a security fix. The way identifiers handled recursion was subtly different to the way aliases did, so that a recursive call to the same alias as an alias or as an identifier would have resulted in different behaviours, one of which would have been to unintentionally pass the command and its parameters to the server. Users will unfortunately need to update their scripts as this change is important enough to keep in place.
|
|
|
|
Joined: Nov 2004
Posts: 842
Hoopy frood
|
Hoopy frood
Joined: Nov 2004
Posts: 842 |
Should this be the case if you're trying to silence output?
E.g. channel { .channel $1- }
Or should it now be: channel { !.channel $1- }
?
What do you do at the end of the world? Are you busy? Will you save us?
|
|
|
|
Joined: Aug 2013
Posts: 81
Babel fish
|
Babel fish
Joined: Aug 2013
Posts: 81 |
The ! should be used any time you want or need to call a built in command rather than an alias by the same name... So, with your example, you would use !.channel
|
|
|
|
Joined: Jun 2009
Posts: 96
Babel fish
|
Babel fish
Joined: Jun 2009
Posts: 96 |
sorry to say but that does not make any sense for someone who spent years scripting for mirc 6 this is dumb all the way
|
|
|
|
Joined: Apr 2010
Posts: 969
Hoopy frood
|
Hoopy frood
Joined: Apr 2010
Posts: 969 |
sorry to say but that's retarded and makes no logic at all for someone who spent years scripting for mirc 6 this is dumb all the way I disagree. The help file specifically says that named aliases can not be called from within themselves. That to access default commands, the "!" prefix should be used. The previous behavior of defaulting to a built in command was undocumented and as such should not have been relied upon.
|
|
|
|
Joined: Dec 2002
Posts: 5,481
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,481 |
One of the reasons I release a public beta is to get feedback on changes like this one that can affect existing scripts. No one reported any issues with this change while the public beta was out, so I decided to leave it in for the final release.
As many of you know, although there are many changes, like this one, that I would like to implement to make the scripting language more consistent, I prefer to maintain backwards compatibility. As it now looks like this change is breaking scripts for a large number of people, many of whom are not technical enough to fix it themselves, I will be reverting this change in the next version.
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
That's because most of the users actually use custom scripts, and those users as well as the authors of those scripts don't try betas. It would probably be a good idea to write a test cases script which use 'everything' of the language, or do you already have something like that?
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Jan 2004
Posts: 1,360
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 1,360 |
Testing isn't relevant here, the scripts were broken on purpose and people beta testing understood that changes must be made; at least that's how I took it.
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
How is it irrelevant Khaled recently stated that quirks are not known unless people report them but with test cases, this is avoided. The point is that if he had such test cases, one of them might have caught the error.
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Jan 2004
Posts: 1,360
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 1,360 |
The error was placed there on purpose, a change in (un)defined behavior. Had this error occurred in a test, it would have been expected and seen as the desired result.
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
I'm not sure what you are talking about, I was talking about writting a script which would make use of pretty much anything in the language, which would check if everything is working as expected, like: alias testing {
if ($gettok(a b c d,2,32) != b) echo -a #1 error
else echo -a #1 success
if ($mid(a b c d,3,32) != b) echo -a #2 error
else echo -a #2 success
join #test_recursion
}
alias join {
join $$1
:error
if (!$error) echo -a #3 error
else echo -a #3 succces
reseterror
} This would have caught the recursion problem when it was introduced
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Jan 2004
Posts: 1,360
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 1,360 |
The error was introduced on purpose. It was a change in expected behavior. 47.Fixed alias/identifier behaviour inconsistency when a recursive call is attempted which could have led to unexpected results. Both now halt the script with an error message instead. I took this to mean that Khaled realized he was breaking backwards compatiblity, and so what would testing have prevented here? Your recursion test produces an error and returns success. Now maybe I'm wrong about Khaled's original intent, in which case the test would have prevented this. But that's not my interpretation of his release notes or subsequent posts. Users will unfortunately need to update their scripts as this change is important enough to keep in place. He will be reverting the change not because it was an accident, but because people are raising a stink about it.
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
I was not talking specifically about this issue but in general, it would save him a lot of troubles to have a test cases script. I think you misunderstood what I was saying because we both know what happened with this issue. This test script would have been run on the version in which recursion was removed (let's say 5.5), not now or for the recent beta, and since calling /join inside that custom /join wouldn't have produced the "error recursive call" message, the script would have warned that it's not working as expected. (whatever what was expected at that time, this script might not be accurate) I took this to mean that Khaled realized he was breaking backwards compatiblity He changed it because trying to do recursion by calling an alias as an identifier and as a command would produce differents behaviors, but regardless, calling the built-in was not correct in this situation.
Last edited by Wims; 30/06/14 11:22 PM.
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Jul 2006
Posts: 10
Pikka bird
|
Pikka bird
Joined: Jul 2006
Posts: 10 |
I am against reverting the change from the argument that this change breaks scripts for users that aren't technical enough to fix their scripts. While I understand the position of a user whose scripts have been broken and doesn't understand what the error message means, the user should be technical enough to find and download an updated script that does work with this change.
Security improvements occasionally break features. I am for reverting the improvement if the feature was a legitimate feature and should be expected to work. However I am against reverting the improvement if the feature was undocumented, accidental, or the result of a bug. Undocumented always means Does Not Exist and/or Subject To Change. Maintaining backwards compatibility with regards to security to appease the masses is not a stance I find attractive to a software vendor.
|
|
|
|
Joined: Dec 2002
Posts: 5,481
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,481 |
I agree, that is why I called it "partially a security fix" because it resolves an inconsistency in the behaviour of aliases and identifiers that has been around ever since the scripting language was created. However it is not a security fix in the sense that it fixes something that is exploitable or that would technically be called security issue. It is a quirk of the scripting language, of which there are many, that a scripter has to be aware of. If it was an actual security issue, I would be leaving the change in. Thanks for your comments on this topic everyone.
|
|
|
|
|