$chr(32) - fix this old bug please - mIRC Discussion Forums

Let's take this script here:

Code:

alias bugz {
  var %a = 1
  while ($mid($1-,%a,1)) {
    echo -a $v1
  }
}

The input:
/bugz why does mirc have bugs?

The output:
w
h
y
* /echo: insufficient parameters

This script will halt whenever it reaches a space, also known as $chr(32), because there is a very old bug where mirc thinks that $chr(32) is a null character.

However:

Code:

alias bugz {
  var %a = 1,%b
  while ($mid($1-,%a,1)) {
    %b = $v1
    if (!%b) { echo -a This should show up for every space the script encounters }
  }
}

will not echo anything, because %b is filled with $chr(32).

There needs to be consistency. This is a long-standing issue, and it forces scripters to make tedious workarounds that should not be necessary.

This is not a bug and is consistent with the way all commands are parsed in mIRC.

See the mIRC Internals Wiki.

Don't tell me it isn't a bug. If a space can fill a variable but it can't be displayed from that variable, that's a bug.

It doesn't work for the same reason typing /echo -a[color:red]<space><space>[/color] doesn't work. That isn't a bug and neither is this. It is intended behaviour, even if it's not desirable to you.

This is an effect of how mIRC parses commands, and it's that simple parsing that makes mIRC a very easy language to learn. Various feature suggestions (hint: that's the right forum) have been made, including a command prefix that would preserve spaces in some way. I suggest you search and add your support to one.

Quote:

Don't tell me it isn't a bug.

It's not a bug. There, I told you.

mIRC uses space as a delimiter for commands, so multiple spaces will always be ignored when evaluating a line of code unless you pass it to mIRC indirectly. It's not that mIRC can't "display" spaces from a variable, it's that mIRC will parse the spaces from the variable and then handle them the way it handles all spaces parsed in a line of code. Those spaces actually *are* passed through the scripting pipeline, but only up to the point where your echo command is evaluated, at which point they are destroyed just like Collective described.

Example:

- The line /echo -a %myvar would turn into "/echo -a MY <space><space> VALUE" after variable interpolation.

- Once executed and tokenized, the arguments would be passed into the "echo" command with $1 = "-a", $2 = "MY", $3 = "VALUE".. meaning $1- = "-a MY VALUE". This is why your spaces seem to disappear, because after interpolation they are no longer "data", they are delimiters in mIRC's syntax.

- This goes for all /commands where tokenization happens for $chr(32). Note that this is why you can preserve spaces (better) using $identifiers, because the tokenize character there is $chr(44).

- This is why $len($str($chr(32),5)) == 5, because it doesn't pass through any /commands which use space tokenization. This proves that mIRC does not destroy your spaces, but uses them as token delimiters in the parsing stage. This proves that this is an inherent syntax rule and cannot be a bug.

Dislike this functionality all you want, but at least have the maturity (and intelligence) to understand that this is a basis of mIRC's syntax and parser and an inherent part of the language, good, bad, or neither.

So it's not a bug, it's a "feature". Got it.

If it makes you feel better, Tcl works the same way-- the only difference is that Tcl has other mechanisms to preserve spaces (and other data that may be parsed as syntax rather than data) that mIRC does not. Fault mIRC for an incomplete solution, but not for the current implementation being buggy.

Well, I did figure out a way around the problem, and that is to use /tokenize.

Well in your specific example you can solve the problem by simply writing a *proper* if conditional:

Code:

while ($mid($1-,%i,1) != $null) { 
...
inc %i
}

because an empty string, $null, $false and 0 are all equivalent in an if condition (when evaluated alone), meaning spaces isn't the only character your original code would fail on-- "0" would be another.. and that is really not a bug.

The problem isn't with the 'while', it's with the 'echo'.

mIRC when it encounters an error, stops..

So when it encounters the echo of a 'space', mIRC fails out.

So, using this would stop the errors:

Code:

var %i = 1
while ($mid($1-, %i, 1)) {
  if ($v1 != $chr(32)) {
    echo -a $v1
  }
  inc %i
}

OR

Code:

var %i = 1
while ($mid($1-, %i, 1)) {
  echo -a Val: $v1
  inc %i
}

if its for your own personal script, you could alway replace $chr(32) with $chr(3) $+ 0,0 or something?

@Bekar:
That while will still fail if $mid($1-, %i, 1) == 0

The proper way is to explicitly test != $null, or check that %i <= $len($1-).. Then you can make sure you're not echoing nothing

Yeah, true :P

Originally Posted By: nimper2000

Let's take this script here:

Code:

alias bugz {
  var %a = 1
  while ($mid($1-,%a,1)) {
    echo -a $v1
  }
}

The input:
/bugz why does mirc have bugs?

The output:
w
h
y
* /echo: insufficient parameters

No one noticed the missing "inc"? ^_^;

And in any case, here's the even easier solution.

Code:


alias bugz {
  var %a = 1
  while ($mid($1-,%a,1) != $null) {
    e $v1
    inc %a
  }
}

alias e {
  !echo -a $+(,$1-)
}

The input:
/bugz why does mirc have bugs?

The output:
w
h
y

d
o
e
s

m
i
r
c

h
a
v
e

0

b
u
g
s
?

$mid is sampling directly from the byte-string you have passed it, which is not influenced by tokenization as has been erroneously stated (or perhaps implied) above. So, $chr(32) has not been "stripped", there. Zero would still negate the original loop condition, though.

$chr(32) is being stripped, instead, at internal tokenization of the echo command. So, I have prefixed the string with $chr(15) in alias e. That's directly written as CTRL+O in most any mIRC text field (editor, editboxes, etc.). It's a non-printed character which acts to delimit and force display of consecutive whitespace, here.

^-: Above, in the code example, the input was, of course:

Code:

The input:
/bugz why does mirc have 0 bugs?

Which was a joke, by the way. ^_^;

Originally Posted By: "rehinged"

...which acts to delimit and force display of consecutive whitespace, here.

I should replace that with: "...which, here, allows the parsed echo command to have invisible content, making blank lines printable." Because, clearly, there's a non-tokenized character there, and it's one which, by it's nature, has no print value. It's better than $chr(160), which actually does get filled with visible characters in some fonts.

I have also used it before to preserve consecutive whitespace in echo lines, though it is more difficult to catch before mIRC tokenizes the string somewhere in its travels.

When you find the spot to use it, it usually goes something like:

Code:

$replace($1-, , ,,)

So, there you're replacing [space] with [^o][space][^o], and ending up with [^o][space][^o][^o][space][^o][^o][space][^o], which the end obviously turns into [^o][space][^o][space][^o][space][^o].