[7.52] $len vs. string of spaces - mIRC Discussion Forums

I was trying to update my /mkpasswd alias to include spaces in a password and pad the string with extra characters if the length didn't meet the specified length I said.

At first I thought I'd coded my alias wrong, but then I noticed this.

Code:

[17:37:37] 39M7iB91BG9 bmdt8mASKlAEVFJbJ9rqa7s4 5Jh A83ZE4NO0bt7B9 YqFcG4B0ZG18i93TE75114qqSKeEgpMH6358ZQCSXPi7 > $len = 100
[17:37:37] 39M7iB91BG9 bmdt8mASKlAEVFJbJ9rqa7s4 5Jh A83ZE4NO0bt7B9 YqFcG4B0ZG18i93TE75114qqSKeEgpMH6358ZQCSXPi7
...
[17:38:54] 6 s f > $len = 100
[17:38:54] 6 s f

Should $len really be classifying "6 s f" as 100 characters if there's more than once space between the 6 s and s f given mIRC's... issues with multiple space handling.

Yes, it should.

Code:

//var -p %a abc $+ $str($chr(32),3)  | echo -a $len(%a) $sha1(%a)
//var -p %a abc $+ $str($chr(32),2)  | echo -a $len(%a) $sha1(%a)

You can see that both $len and $sha1 see the string changing depending on how you edit to add or remove spaces, because they're identifiers. So it's legit to consider the spaces as part of $len. If we had /len instead of $len, it wouldn't see the extra consecutive spaces.

Since /write and /echo are commands, we lose the extra spaces. It would be nice to have $echo and $write so a theme intercepting :TEXT: would be able to preserve spaces without using $chr(160) to fake it or using &binvars, as well as being able to write consecutive spaces to disk without using /bwrite.

I could totally support some kind of $rawstr for preserving spaces in mIRC which could then be used in sockwrite, echo, etc.

Quote:

I could totally support some kind of $rawstr for preserving spaces in mIRC which could then be used in sockwrite, echo, etc.

Unfortunately, this would not work. The moment an identifier is evaluated and a command/identifier is parsed in order for it to be executed, the extra spaces would be removed. This happens throughout the script parser in many different contexts.

At the risk of repeating this feature suggestion ad nauseam, I believe that many people here would still be very happy with a partial and limited solution for that problem. Something along the lines of a new command prefix (/^echo ..) or special command (/keepspaces echo ..) where just the command parser preserves spaces, by including extra spaces in the argument tokens [*]. After all, spaces.dll shows that at least a few of the most important built-in commands (/echo, /msg) would work just fine that way, likely as well as many others. Being able to use some of those basic commands without loss of spaces would probably take care of 90% of the spaces-related problems people run into, which would be great even if resolving the other 10% will never happen (I am making up these numbers of course). For example, such a simple extension would be a huge step towards proper scriptable support for theming. If that new extension comes with an explicit disclaimer that it is provided as-is and will not work for everything, then what's the harm?

I apologize for re-posting this suggestion every once in a while, but I would very much like to be able to stop having to maintain spaces.dll..

[*] For example splitting "foo(space)(space)bar" to the arguments array of ["foo", "(space)bar"], which is how spaces.dll works as well.

I agree, this would be a great step toward better support of spaces in commands.

A private beta could be released for such a change so that people can try to see if this is making some commands not working properly.