Hi!

$gettok(a.b..d.f,3,46)

shouldnt this return $null ?

By design, token identifiers ignore null tokens.

...and no re-design in sight?

no redesign in sight, this is related to the issue of ignoring duplicate consecutive spaces. Any re-design here would break a high percentage of existing scripts.

Quote:

would break a high percentage of existing scripts.

I get so tired of reading that. Scripts are supposed to
conform with mIRC, not vice-versa. If a few scripts break
because of evolution in the mIRC scripting language, then
so be it, they can be fixed. Broken scripts shouldn't have
any weight whatsoever in any decisions to make changes
to the language.

You could always ask for some kind of .prop value that returns null values. That way the $gettok() identifier (And other $*tok*() identifiers.) are "fixed", and no scripts would be broken.

It'll also help me as well, since I plan on writing an IRCd with a "proper" config at some point.

I like the idea of a $prop to not ignore null tokens...

I also wrote a DLL awhile back that can do this...

Nobody except Khaled can know for sure, but I too think it's not going to happen. A .prop is a much better (and plausible) idea.

In the meantime, if you're interested in a scripted solution, you may find this handy:
It works exactly the same way as $gettok() except it supports null tokens. The only catch is that it won't work correctly if the input string contains linefeed (ASCII 10) characters, quite unlikely with strings meant for IRC. Adding support for LF while preserving the original functionality would slow down the alias (because it would have to be more complex). It's not worth it imo, considering the rarity of the cases where LF is present in the input.

Wow, that's pretty neat.

var %a = 1

while ( a% <= $gettok(a.b..d.e.f.,0,46)) {
var %b = $gettok(a.b..d.e.f.,%a,46)
...
...
...
inc %a
}

I still think you gain alot more to use $null
and mirc are the only one having this behavior and current behavior are probably causing more problems than it solves.

best would be "array %list[10]" <--- this will save many lives :)=

To avoid problems where null token causes script to se $gettok(a.b..d.e,4,46)is 'e' instead of 'd', you can use placeholder of a character that will never appear in the string. Such as checking to see if you are storing a NULL token and storing $chr(3) instead. Then, when retrieving tokens, you use $remove(token,$chr(3)). It doesn't matter what you use in place of $chr(3), as long as it's something that should never appear in the string.

Or: return $iif(token == $chr(3),$null,token)

That is not very consequent with how /filter -t sorts, it fails to sort as intended, due to consecutive token separators.