Project

General

Profile

Bug #5078

open

$regsubex() parsing brackets issue

Added by westor (GR) almost 2 years ago. Updated 5 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
Scripting
Target version:
Start date:
07/10/2020
Due date:
% Done:

0%

Estimated time:
Operative System:
All
Regression:
No

Description

Hello,

I was trying to use the following tiny code, the issue seems to be in line 14 with $regsubex() and probably under the brackets that needs to parse [[ \n ]] or [[ \ $+ t ]] , the truth is that i couldn't reproduce the issue at 100% to make a clean report, maybe you can track down the issue better using that code.

alias big {
  if (!$0) { echo -atic notice * Usage: /.big <text> (and without the dot) | return }
  var %big = $chr(32) $+ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`{|}~
  var %big1 = .. .xx. xx..xx .xx..xx. xxxxxxx. xx..xx .xxx.. .xx ...xx xx... ...xx... ...... ... ...... .. ....xx .xxxx. .xxxx xxxxx. xxxxx. ...xxx. xxxxx .xxxx. xxxxxx .xxxx. .xxxx. .. ... ....xx ...... xx.... xxxxx .xxxx. .xxxx. xxxxx. .xxxx. xxxx.. xxxxx xxxxx .xxxx. xx...xx xxxx ....xx xx..xx xx... xx....xx xx..xx .xxxx. xxxxx. .xxxx.. xxxxx. .xxxx. xxxxxx xx..xx xx....xx xx...xx xx...xx xx..xx xxxxxx xxxxx xx.... xxxxx ..xx.. ...... xxx. ...xx .xx. xx... .xxx.xx
  var %big2 = .. xxxx xx..xx xxxxxxxx xx.xx... ...xx. xx.xx. xx. .xx.. ..xx. xxxxxxxx ..xx.. ... ...... .. ...xx. xx..xx xx.xx ....xx ....xx .xx.xx. xx... xx.... ...xx. xx..xx xx..xx xx .xx ..xx.. xxxxxx ..xx.. ...xx xx..xx xx..xx xx..xx xx..xx xx.xx. xx... xx... xx.... xx...xx .xx. ....xx xx.xx. xx... xxx..xxx xxx.xx xx..xx xx..xx xx..xx. xx..xx xx.... ..xx.. xx..xx xx....xx xx...xx .xx.xx. xx..xx ...xx. xx... .xx... ...xx xx..xx ...... ..xx ..xx. .xx. .xx.. xx.xxx.
  var %big3 = .. .xx. ...... .xx..xx. xxxxxxxx ..xx.. .xxx.x ... xx... ...xx .xx..xx. xxxxxx xxx xxxxxx .. ..xx.. xx.xxx ...xx ..xx.. .xxxx. xx..xx. xxxx. xxxxx. ..xx.. .xxxx. .xxxxx .. ... xx.... ...... ....xx ..xx. xx.xxx xxxxxx xxxxx. xx.... xx..xx xxxx. xxxx. xx.xxx xxxxxxx .xx. ....xx xxxx.. xx... xxxxxxxx xxxxxx xx..xx xxxxx. xx..xx. xxxxx. .xxxx. ..xx.. xx..xx .xx..xx. xx.x.xx ..xxx.. .xxxx. ..xx.. xx... ..xx.. ...xx ...... ...... .... xx... .xx. ...xx .......
  var %big4 = .. .... ...... xxxxxxxx ...xx.xx .xx... xx..x. ... .xx.. ..xx. xxxxxxxx ..xx.. .xx ...... .. .xx... xxx.xx ...xx xx.... ....xx xxxxxxx ...xx xx..xx .xx... xx..xx ....xx xx .xx ..xx.. xxxxxx ..xx.. ..... xx.... xx..xx xx..xx xx..xx xx..xx xx... xx... xx..xx xx...xx .xx. xx..xx xx.xx. xx... xx.xx.xx xx.xxx xx..xx xx.... xx..xx. xx..xx ....xx ..xx.. xx..xx ..xxxx.. xxxxxxx .xx.xx. ..xx.. .xx... xx... ...xx. ...xx ...... ...... .... ..xx. .xx. .xx.. .......
  var %big5 = .. .xx. ...... .xx..xx. .xxxxxxx xx..xx .xxx.x ... ...xx xx... ...xx... ...... xx. ...... xx xx.... .xxxx. ...xx xxxxxx xxxxx. ....xx. xxxx. .xxxx. xx.... .xxxx. .xxxx. .. xx. ....xx ...... xx.... ..xx. .xxxxx xx..xx xxxxx. .xxxx. xxxxx. xxxxx xx... .xxxxx xx...xx xxxx .xxxx. xx..xx xxxxx xx....xx xx..xx .xxxx. xx.... .xxxxxx xx..xx xxxxx. ..xx.. .xxxx. ...xx... .xx.xx. xx...xx ..xx.. xxxxxx xxxxx ....xx xxxxx ...... xxxxxx .... ...xx .xx. xx... .......
  set -eu300 %_bigrb $iif(%_bigrb,$gettok($v1,2-,32) $gettok($v1,1,32),$regsubex(4 7 8 9 11 12 2 6 13,/(\d+)/g,0 $+ $chr(44) $+ \1))
  var %string = $regsubex($replace($upper($1-),$chr(160),$chr(32)),/[^\Q $+ %big $+ \E]/g,)
  var %i = 1
  while ($evalnext($+(%,big,%i))) {
    var %bigi = $v1
    var %bigi = $regsubex(racc,%string,/(*UTF8)(.)/g,$regsubex(coon,$gettok(%bigi,$poscs(%big,\t),32) $+ $chr(32),/(x+)/g,$chr(3) $+ $gettok(%_bigrb,$calc(( [[ \n ]] -1) % 9 +1),32) $+ [[ \ $+ t ]] $+ $chr(3)))
    $iif($show,say,echo -a) $$replace(%bigi,x,.,.,$chr(160))
    inc %i
  } 
  if (!$event) && (!$editbox($active)) editbox -ap /big
}

- Thanks!

#1

Updated by Oui Ouims 5 months ago

Note on this to help you fix it eventually.

In mIRC when you're doing nested $regsubex construct like this $regsubex(name,abcd,/(.)/g,$regsubex(name1,1234,/(.)/g, <here>) :

[[ \ $+ t ]] 

is a necessary construct to access the marker of the nested $regsubex, if you use \t, then \t will have the value of \t from the first $regsubex, because the markers are replaced everywhere in the rest of the code, $regsubex(name,pattern,$regsubex(replacename,patternnest,subtext)) < in this \t would be replaced in the whole nested regsubex, inside 'replacename', 'patternnest' and 'subtext'.
\t would return nothing because it would be converted as $1, which would be $null when it gets evaluated
Using \ $+ t does not work because $regsubex must not evaluate the subtext until it made the regex call to the engine, so you would just end up with plain text \t.
Because the double bracket are spaced out, they are changed to [] internally before the line is evaluated.
When the evaluation takes place, the first $regsubex evaluates, find its matches, at this point, this part of the code looks like [ \ $+ t ] still.
Once the nested $regsubex evaluates because we're replacing, that's only when [ ] takes place, and it becomes \t from that nested $regsubex's point of view only.

[[ \n ]] 
is necessary to get the value of that marker from the first/outer $regsubex call, for example, if this is the second match from the first regsubex, match is on 'b' and \n is 2, if you want to get the 2 from <here>, you have to use
[[ \n ]].

\n and \ $+ n would return nothing and plain text \n, same as using \t and \ $+ t above.

Using

[[ \n ]]
would result in the nested $regsubex being $regsubex(name1,1234,/(.)/g, [ \n ] ), and again, the [ ] are evaluated when the nested $regsubex evaluates, this time evaluating \n at the correct time.

It seems that adiirc is sort of aware of the above:

//echo -a $regsubex(name,abcd,/(.)/g,$regsubex(name1,1234,/(.)/g, <here [[ \n ]] -- [[ \ $+ 1 ]] >))


mIRC : <here 1 -- 1 ><here 1 -- 2 ><here 1 -- 3 ><here 1 -- 4 ><here 2 -- 1 ><here 2 -- 2 ><here 2 -- 3 ><here 2 -- 4 ><here 3 -- 1 ><here 3 -- 2 ><here 3 -- 3 ><here 3 -- 4 ><here 4 -- 1 ><here 4 -- 2 ><here 4 -- 3 ><here 4 -- 4 >
Adiirc: <here -- 1 ><here -- 1 ><here -- 1 ><here -- 1 ><here 1 -- 1 ><here 1 -- 2 ><here 1 -- 3 ><here 1 -- 4 ><here 2 -- 1 ><here 2 -- 2 ><here 2 -- 3 ><here 2 -- 4 ><here 3 -- 1 ><here 3 -- 2 ><here 3 -- 3 ><here 3 -- 4 >

There's an "off by one". The first execution of the inner $regsubex for the first match of the outer $regsubex are incorrect, aka the first four <here...>
But the second and following executions result in values which are correct for the previous execution, aka the the 4th <here> token is what the first <here> token should have been.
I'm not sure if it's an off by one in the source code or if it's just a coincidence because I'm having difficulties understanding why the

[[ \ $+ 1 ]] 
construct shows a constant '1' in the first four <here>

Also available in: Atom PDF