Forums Bug Reports Command silencing propagation inconsistency

Normally, if a command that is silenced with the . prefix receives an identifier-type alias as a parameter, the silencing effect of the command will be propagated to any applicable line of code within the alias as well. However, if the command is dynamically-coded (e.g., as a variable), this silencing-effect propagation will not occur if the . prefix is prewritten into the dynamically-coded command's value1 (even though the command itself will be silenced as expected2), and the prefix will have to be manually affixed to the dynamically-coded command to achieve this behavior instead2:


/runqpfxtests - Tested on v7.76 and beta v7.76.2477

1. as demonstrated by %dcsB / Test 4 of the example script
2. as demonstrated by %dcsC / Test 5 of the example script
3. as demonstrated by %dcsD / Test 6 of the example script

Thanks for your bug report and the test script. Variables are parsed in a different way, and at a different point, in the script parser than command prefixes. This behaviour has been in place for as long as I can remember. Changing where and how command prefixes and/or variables are parsed after all these years would introduce side-effects and/or break existing scripts. As you have found, the solution is to specify the prefixes at the start of the command line.

Well, the other command prefix '!' is parsed correctly from a %variable though:
//alias echo !echo -ag custom echo called | var %!noop !echo -ag ok | [ %!noop ] | alias echo


More about the silencing '.':
- https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/270904/ In this thread you fixed the '!' command prefix being propagated to the first command associated with the if/while/else, however you did not touch the '.' silencing behavior despite Iire asking about it specifically in the last post.
- https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/162820/ this is a more known about behavior of the '.' where $show changes to $false inside a silenced command while the original routine was an alias called normally, reported a lot but never fixed

But this defeats the purpose of having a dynamically created command 'call' including the prefixes.
In fact, creating dynamic custom command call is a way to get rid of some cascade of if/elseif statement to dispatch stuff (function pointer if you will).

Given all those informations, would you reconsider fixing '.' and $show's behavior? Please keep in mind that for a script to break after fixing any of this, it would have to be using dynamic command call with silencing prefix and expecting it to not silence it, or silencing an if statement and expecting it to silence the first command which belong to that if statement only, or expect $show to change from $true to $false inside a silenced command when it was $true before it. Those can only be wrong expectations.

Nice try :-) That is part of the variable definition and can appear anywhere in a command. It has nothing to do with command prefixes.

Both items were hopefully fixed as mentioned in versions.txt, 27/11/2022 - mIRC v7.72, 11.Fixed !. command prefixes used infront of while/if commands affecting following command.

This is a similar issue to the current post.

I had already looked through the code when I posted my first reply, however I looked through the code again and now I am even more uneasy about the idea. The /!. prefixes are meant to be parsed once a command is fully formed and ready to be executed. In the case of the original post, the variable is not a command yet. It is sent to the variable parser to be evaluated in order to form the final command, which can then be executed, and only then are the prefixes parsed and applied. What you are requesting is for the evaluation parser to make assumptions about the start of the line during the process of evaluation, before the line has been fully constructed, and to apply these to all subsequent identifers/variables/etc. - not once the entire command line has been constructed and is ready to be executed, as has always been the case.

As you know, I generally try to avoid making changes that can affect backward compatibility, so this is not a change I would make.

I meant to show the built-in 'echo' command is called instead of the custom echo alias just created:
//alias echo !echo -ag custom echo called | var %exec !echo -ag ok | [ %exec ] | alias echo
The [ ] are required from the editbox to force a commnand starting with a variable (or $ident), I got rid of the ! inside the variable name, hopefully this is clearer.
That being said, I understand this is unrelated to the issue.

My bad then, I hadn't tried it.

This is how I view it as well, however I did not realize it means this report is invalid because indeed $testqpfx() is evaluated before knowing the command has the . prefix.

I realize now as well that $show is a global value, not a local identifier, which is why it changes per routine whenever you have silenced command, with mIRC reverting back the value to the original value:

alias temp echo -ag $1
alias myalias echo -ag $show | .noop $temp($show) | echo -ag $show
/myalias will echo $true, $false, and $true again

I suppose that's just the way it works then, and there's no issue so to speak, after all.