!-command-prefix bug - mIRC Discussion Forums

It seems that if the ! mIRC-internal-command prefix is applied to the—for lack of better term, "construct commands" (i.e., those which introduce a new scope like /if, /elseif, /else, or /while), mIRC will attempt to also apply the ! prefix's behavior to the first command that occurs in the newly created scope if that command appears on the same logical line as the so-called "construct command". In other words, given:

Code

alias -l local_alias { echo -ga local alias invoked }

alias pfxtest_1 {
  !if ( $true ) {
    local_alias
  }
}

alias pfxtest_2 {
  !if ( $true ) { local_alias }
}

...calling /pfxtest_1 will work as expected, while /pfxtest_2 will cause mIRC to attempt to find and call an internal command named /local_alias, then forward the command call to the active server when it fails to do so, rather than call the alias of the same name.

Though I don't include these tests in my sample script above for the sake of simplicity and readability, I've so far tested this behavior with several aliases of the following properties, with no variation in the behavior:

local vs. global
file-internal vs. file-external
positioned-before vs. positioned-after (both script and file-wise)
defined within remote file vs. within alias file

It also appears to make no difference whether or not { } / braces are used around the command, if a condition is wrapped in ( ) / parentheses when applicable, nor if the behavior-testing alias is called via script or editbox. Additionally, and as hinted at earlier, the buggy behavior will occur if the $& identifier is used in an effort to visually split the custom command from the line that "construct command" appears on - e.g.:

Code

alias pfxtest_3 {
  !if ( $true ) { $&
      local_alias
  }
}

(...I'm unsure why anyone would actually do this sort of thing though...)

This behavior does not (cannot?) occur if the alias is used as an identifier - e.g.:

Code

alias pfxtest_4 {
  !if ( $true ) { $local_alias }
}

...will call $local_alias as expected.

(Tested on a clean installation of mIRC v7.71 on windows 10 home edition.)

Upon further testing, it seems a similar sort of behavior occurs when the . prefix is used to "silence" the "construct command", except that it, of course, simply runs the first alias in quiet mode, (i.e. with $show == $false), if it occurs on the same logical line. Unlike the ! prefix buggy behavior, however, this will occur even if the alias is used as an identifier - given:

Code

alias -l quiet_alias {
  echo -ga silenceable alias invoked as $iif( $isid , an identifier , a command ) with $!show == $show
  echo -gaq this message is only visible in verbose mode
}

alias pfxtest_5 {
  .if ( $true ) {
    quiet_alias
  }
  .if ( $true ) {
    $quiet_alias
  }
}

alias pfxtest_6 {
  .if ( $true ) { quiet_alias }
  .if ( $true ) { $quiet_alias }
}

.../pfxtest_5 will print both messages within /quiet_alias in both cases, while /pfxtest_6 will only print the first (non-silenceable) message in both cases.

Hey, this behavior was reported in the past for the dot/silencing, since it was not fixed I assume it's intended, I have not seen the '!' being reported this way, but it seems equally intended.

Huh... while I can't necessarily doubt it, it would seem pretty odd to me if that is the case.

Do you happen to have a link to a post where that behavior was reported/discussed before? I tried searching but haven't yet had any luck finding one that mentions the silencing of /if and the like.

Can't find anything, this is the closest I found https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/162820/

It could be related but doesn't really talk about passing the state forward.

I don't like this behavior anyway so if it has never been reported and is a bug, I'm not against a fix

I think it might be this post: https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/261709

Thanks this has been fixed for the next beta. This actually affected both if and while, since these are intrinsic commands that cannot be overriden in the first place.

👍 So, the ! prefix variant of this bug does indeed appear to be fixed as of the latest two beta versions; however, it seems the . prefix variant I described in my followup reply - where the first command or alias after a "silenced" /if, /while... etc. will also be silenced if (and only if) they're placed on the same logical line together - still persists.