Hey
1) is just a bug, allowing binvar name with space in them means no manipulation possible with commands as you said, and that basically defeats the purpose of having such binvar name. it should report an error immediately
1.1) related topic is loading item name with space with /hload by editing an item name in a file manually, $readini $ini etc are also affected, it would be great to be able to have better control over this, /hload could get a new switch to a) return an error when an item with space is found b) accept the item name with space (default) c) accept the item but convert all spaces to underscore or something.
$readini & $ini could get a new switch ($ini doesn't have switch but there recent $ini suggestion taking some) to a) prevent a match if the item/section name contains spaces (for both text comparision and if the Nth item/section refers to an item/section with a space, for $ini)
2) $urlgetdir wouldn't solve anything, it wouldn't be sandboxing much as that value could then points to $mircdir anyway, I don't think dcc related settings should be applied either to get the dir.
It's all command and identifiers which starts at $mircdir except for $urlget, $getdir isn't even an exception because it's doesn't take a parameter used by mirc to read or write to/from it, it's mainly using the parameter for string comparison without checking the existence of the file.
2.1) As discussed on IRC $urlget, with a file target parameter value of "subfolder\filename.txt" $urlget does NOT make the complete filename starts at $getdir but at $mircdir, whereas using a file target parameter of "filename.txt" does make the complete filename starts at $getdir. Both are easily called "relative path" but they don't end up using the same path, this I consider a bug if $urlget is always meant to make relative path starts at $getdir instead of the usual $mircdir. I wrote a post in the past about how I believe it should be made consistent with other identifiers and always use $mircdir for relative path but between it being the only identifier doing that and the fact that "subfolder\filename" starts at $mircdir anyway, which is inconsistent for $urlget itself, I think backward compatibility are compromised for $urlget anyway and that it should be changed. Think of it like the on keydown event, that was also trying for years to combine both keypress and resulting characters, resulting in new on char event added, which broke compatibility for the on keydown event but we ended up with a much better feature.
3) I think that .. and . should be handled the same in all identifiers and command's parameter which are used by mirc to read and write to/from file, but that would break compatibility in a bad way. There's already a lot of different behavior, $sfile won't work with .. but $findfile will. I believe most commands and identifiers decodes .. properly though, maybe only a couple don't, so I'd say $urlget should decode them correctly, there's many way to screw up with a powerful language like msl, limiting functionalities because of the argument 'it's dangerous' makes no sense given what you can already do.
