mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Aug 2013
Posts: 82
I
Iire Offline OP
Babel fish
OP Offline
Babel fish
I
Joined: Aug 2013
Posts: 82
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:

Code
alias -l testqpfx {
  !inc -u0 %tnum
  
  !var %exp = $iif( $show == $1 , $true , $false )
  !echo -ag  Test %tnum - $2 $iif( $1 , verbose , silenced ) evaluation $3 
  !echo -agq  This should $iif( !%exp , not ) appear, ($show expected to be $1) 
  !return  Test %tnum - 98, $+ $iif( %exp , 44[ PASS ] , 52[ FAIL ] ) $+ 
}

alias runqpfxtests {
  !echo -ag $testqpfx( $true , Hard-coded )
  !linesep
  
  !.echo -ag $testqpfx( $false , Hard-coded )
  !linesep
  

  !var %dcsA = !echo -ag, %dcsB = !.echo -ag , %dcsC = !.echo -agq , %dcsD = echo -ag
  
  %dcsA $testqpfx( $true , Dynamically-coded )
  !linesep
  
  %dcsB $testqpfx( $false , Dynamically-coded , with command as / $+ %dcsB  )
  !linesep
  
  %dcsC $testqpfx( $false , Dynamically-coded , with command as / $+ %dcsC )
  !linesep
  
  !.%dcsD $testqpfx( $false , Dynamically-coded , with hard-coded command prefixes )
  !linesep
}

/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

Joined: Dec 2002
Posts: 5,491
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,491
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.

Joined: Jul 2006
Posts: 4,186
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
Quote
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.
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

Quote
As you have found, the solution is to specify the prefixes at the start of the command line.
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.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,491
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,491
Quote
Well, the other command prefix '!' is parsed correctly from a %variable though:
Nice try :-) That is part of the variable definition and can appear anywhere in a command. It has nothing to do with command prefixes.

Quote
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.
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.

Quote
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
This is a similar issue to the current post.

Quote
Given all those informations, would you reconsider fixing '.' and $show's behavior?
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.

Joined: Jul 2006
Posts: 4,186
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
Quote
Nice try :-) That is part of the variable definition and can appear anywhere in a command. It has nothing to do with command prefixes.
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.

Quote
Both items were hopefully fixed
My bad then, I hadn't tried it.

Quote
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.
Quote
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.
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.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel

Link Copied to Clipboard