Fortunately, as it turned out, the erroneous third function call is made without passing the $0 parameter (function name) to the function. Yes, yes, for some reason, with this erroneous call, $0 is empty. This allows you to implement software insurance against erroneous execution within the function itself. Let’s do it this way, let’s say there is a function:
:global myFunc do={:log info “Hello world !”}
If we ask you to do it twice:
[$myFunc]; [$myFunc]
As we have already found out, it will be executed three times.
Adding a name check in $0 fixes the problem.:
:global myFunc do={
:if ([:len $0]!=0) do={
:log info “Hello world !”}
}
If there is a check for $0, then if the third run is erroneous, the body of the function code will simply be ignored (it will not be executed). This check is performed by checking the condition string : if ([$len $0]!=0) do={ }.
Unfortunately, this error has not yet been fixed by the developers of Microtik. For correct operation, such a check can be inserted into each user function.
Why would I insert :return “” (return “nothing”) into a working function that normally should return something meaningful. I’d rather insert my own :len check for the function name, which is empty with a false third trigger (Microtik idiocy) and the function body will not work.
Not that I understand much of what you (and rextended and optio) posted , but let’s disambiguate this not-so-trifling detail, it is EITHER:
if ([**$len $0]!=0) do={ } OR:
if ([:**len $0]!=0) do={ }
Well, it’s a typo, I wrote it quickly. It’s clear to a fool that : instead of $. What’s the difference? Why find fault with this? The principle and solution are shown.
But it is not necessary to call functions inside square brackets in case where return value is not handled and then there will be no issues. This is not ObjC
Yep, if it is a typo, now that it has been noticed, please correct it, this way there won’t be any doubt.
In this particular case using $ instead of : does not cause an error (in which case a fool would notice that), but rather it returns always true (which may well go unnoticed).
But it is not necessary to call functions inside square brackets in case where return value is not handled and then there will be no issues. This is not ObjC >
Yes, that’s absolutely true and many people know about it. But thanks again for saying it here. Could any of the respected gurus please explain why this happens:
I mean why if we call a function twice without square brackets - everything works fine, but the bug appears only if we call it twice without using it (for example, without assigning the result) and only when enclosing the call in square brackets?
By themselves [] with the content inside means “execute” what is inside. But it is executed anyway, if it is not an expression. Apparently there is some bug in the Router OS command interpreter (if it is a bug, and not something else) that causes such a feature of the work (that with a double consecutive call in the frame [$myFunc]; [$myFunc] - an erroneous third call is triggered due to when the return of the function is “not used”
Amm0 once tried to explain to me why this happens, but I really didn’t fully understand “why ?”.
I would also like to know the guru’s opinion on:
As I wrote above, “why does this happen?”
Is this really an error in the “command parser” (interpreter) of Router OS or whatever it is called (specialists know better) or is this a feature of the work that cannot be avoided?
If this is a bug, then why, despite the fact that information about it was published a long time ago, do not the developers of Router OS fix it? (options: they can’t, they don’t think it’s necessary to fix it because it can be avoided in scripts, they’re afraid of disrupting the work of scripts already written by someone, they really don’t know about this bug, they ignore us, or another reason?
Obviously it is related to interpreter, but hard to tell exactly why, it is not open source, we can only speculate. IMO it is not strict enough and allows performing code with buggy behavior when code is written as not expected by its rules, but some rules are not fully documented.
In this case when function is performed inside interpreter expect return value assigned to variable and when code is not written like that it goes into some buggy flow, if interpreter was made more strict then it will not allow to execute such code that will break some rule to be performed correctly.
See also something similar here → http://forum.mikrotik.com/t/conditional-not-boolean-bug-with-onerror-new-in-7-13/172543/19
, but let’s disambiguate this not-so-trifling detail, it is