Hello, this report was actually reporting multiple issues.
So passing only a %variable name to /bwrite without -t preserve tokenization.
But if that were the only purpose of this syntax (which is a nice feature I wasn't aware of, don't get me wrong), then the following:
//var -s %a % $+ b $chr(32) B,%b A | bwrite -c test 0 -1 %a | var %r $read(test,tn,1) | echo -a space would be lost due to /echo but: len: $len(%r) -- %r
It shows that mIRC is doing much more than just not tokenizing.
mIRC sees that the content of %a starts with a variable (%b in this case), it evaluates that variable (which results in double evaluation, which is very
dangerous) and then completely ignores the rest of the content of %a, which would be
in this case.
I would expect bwrite to write the plain text
text to the file there.
The only other command which document this syntax with seperated "text|%var" is /sockwrite, and "/sockwrite socket %var" does not prevent the tokenization of %var, nor does it have this behavior of only evaluating the first token if it's a %variable & ignoring following tokens.
Regardless if this "weird" behavior was implemented on purpose, it would break backward compatibility to change /bwrite (or /sockwrite eh), but maybe we could get some new switch to rectify this and improve others commands:
- a new switch for /bwrite which makes it so the %variable is not tokenized, preserving spaces, but nothing gets double evaluated either ($unsafe cannot be used)
- a new switch for /sockwrite, honoring the text|%var syntax, where if only a variable is passed, no tokenization happens.
- a new switch for /fwrite, improving the syntax to support text|%var, where it would also prevent the tokenization of the variable