mIRC Homepage
Posted By: Wims Tokenization on spaces with command - 15/06/14 04:01 PM
Code:
alias weird {
var -s %cmd $str($chr(32),$1) $+ weird1 param1 param2
%cmd
}
alias weird1 {
echo -a $!1: $1
echo -a $!2: $2
}
Executing /weird 2, the command executed when evaluating %cmd is " weird1 param1 param2" with two spaces in front of the command.
However, here it doesn't trim the spaces when tokenizing parameters, which results in $1- being shifted, the first parameter $1 returns the name of the alias being called, and $2 the real first parameter etc..
Executing /weird 0 works as expected, I'd expect the two spaces to be trimmed. Tested on 7.32
Posted By: Khaled Re: Tokenization on spaces with command - 16/06/14 08:01 AM
This is happening because script processing does not have explicit and consistent support for handling spaces. In some script-related routines, spaces will be removed, in others they will not. This has been the case ever since the scripting language was created. Making even small changes to this in one or two routines, especially the tokenizing routine, would affect all existing scripts.

One way to make mIRC handle spaces consistently would be to maintain the current method for all existing scripts and to add support for an "options" command at the top of the script that enables alternative space handling. The "options" command could also be used for enabling/disabling other scripting features in future. Any script that contains "options +spaces" would enable strict space handling and all spaces would be retained at all times (which would probably require scripters to rethink how they handle them and to redesign their scripts). That said, I have not looked into how viable this approach would be yet.
Posted By: Wims Re: Tokenization on spaces with command - 16/06/14 04:14 PM
Interesting.
Trailing spaces and consecutives spaces are always removed correctly in my test, but leading spaces are never removed.
If that's correct, it means changing this would only affect people who were adding leading spaces on commands on purpose, knowing mIRC wouldn't trim them while it probably should.
The number of such scripts used today cannot be significant. With that in mind I would prefer to see those leading spaces trimmed where they aren't, a scripter is wrong if he uses that, I was myself using something like $remove($gettok($timer(x).com,2,124),else) to execute a command when finding this.
Really I see no reason why this shouldn't be fixed, there is no problem with backward compatibilities imo, there is nothing to support, using leading spaces to get $1- shifted is not useful in any way and should never have been used in the first place.
Adding a new command /options has more chance to break a script than fixing this issue has. Also, I'll fix all the script being broke by such a change laugh
If it's not correct, in which situation are leading spaces removed?
Regardless of the issue, we do need a way to keep spaces, but it's not like we need that often, rather the opposite, so we should really be able to enable/disable the feature per command (unsure if that's what you meant).
More importantly, being able to disable the feature inside a 'line' would be even better, in the past, a $sp construst like $+ has been suggested, where mIRC would retain spaces inside two $sp:
//echo -a a  b $+ $sp c  d $sp
would echo "a b c  d" or something like that.
I'm not sure if that's too complicated or not but seems like perfect to me, what do you think about it?
© mIRC Discussion Forums