mIRC Homepage
Posted By: Wims Resolve path - 21/03/23 07:32 PM
There's no way to resolve a path containing some \..\ to go to the previous folder.
In this thread : https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/230726/ it's mentioned and I state that .. in path works everywhere.

Well $sfile does not support .. in path, and it would still be great to be able to get full path.

$samepath could be extended with two prop .path1 .path2 to access either value but resolved instead of returning a bool value but it's possible to do this with $file and a new prop there as well.
Posted By: maroon Re: Resolve path - 05/05/23 02:39 PM
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 \.\
© mIRC Discussion Forums