This would be great. Perhaps a more universal solution would be to have a .prop that makes $nofile() and $longfn() resolve '.' and '..' to show the 'real' path. This would allow either using $nofile().prop to sanitize the $sfile input parameter, or for scripts using the return value from things like $findfile(..,*,1,echo -a $parms) to use $longfn($parms).prop to see what they've really got there.
This would make it easier to verify the true target location, where - if the $longfn().prop return string begins with $mircdir - that it would 100% be pointing to somewhere within mIRC's folder tree, and that if $nofile(target).prop doesn't match $mircdir $+ scripts then 100% it's not going to point to your scripts folder.
//if ($mircdirscripts != $nofile(.\scripts\remote.ini)) echo -a safe to download into $v2
//var -s %b $numtok($mircdir,$asc(\)) - 1 , %path $str(..\,%b) $+ windows\system32\test.dll) , %longpath $longfn(%path) | if ($mircdir* iswm %longpath) echo -a safe to download into $v2
I'm not so sure that the $longfn() default behavior without a .prop should be changed to resolve .. and . in paths without a .prop. Because strings containing ..\ and ../ are equivalent, and ..test is a valid foldername and filename, some scripts can try to detect shenanigans by waiting until obtaining the $longfn() string before checking if the path contained \..\ or \.\
