I wanna parse symbols in mirc, well replace them with underscores. I tried this:



But all I get is:



How do I do this?

You have an odd number of parameters. Add another ,_ after your last $chr(63).

So it would be:

Note that you're much better off with a regex:

Dunno if this is of use at all...

Your $chrs
33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 58 59 60 61 62 63 64 91 92 93 94 96 123 124 125 126
equal the octals
41 42 43 44 45 46 47 50 51 52 53 54 55 56 57 72 73 74 75 76 77 100 133 134 135 136 140 173 174 175 176

So you alternatively could use:


But as $mknickfn() of your symbol stringis:you'd only have to replace the remaining chars: ()-[]^`{}
For example:which is the same as(note that the "]" and "-" in the character class require escapes... that's why I prefered to work with octals)

However, $mknickfn() will replace additional chars, more than given in your alias. Only the "replaceIt2"-alias will exactly do the same as your - completely valid - $replace-approach.

Edit: like argv0 points out, it all depends on whether you want to replace a specific set of chars, or everything BUT a specific set of chars.

Thanks guys but still having problems here.







I hate parsing x.x

using a , inside an identifier will confuse mIRC, use $chr(44) instead.

I highly suggest using my regex, its far simpler than any of the others provided.

I can't do that because the input I'm reciving has it I can't tell the input please use $chr() that's why it needs to be parased somehow.

Going into more detail about this issue

Code


Test Command


Results


Can't really thing of any other things mirc can't process

After lots of testing.

Mirc can parse these:


Mirc cannot parse these:


Note: Some things I've listed in cannot parse can be parsed on their own but with other characters they can't.

Slow down.

You're confusing the issue.

I'm not sure this can be explained in one message, but I'll try.

mIRC, like any programming language, has "special" characters that have syntactical meaning to how the language works.

The symbols you listed that mIRC "can't parse" are a list of those very special symbols. You cannot use those characters literally in your scripts. You must escape them. One way to escape a special character is to use $chr(N) where N is the ASCII value of the character. This is why I suggested using $chr(44) for the comma. Similarly, if you want to use a "#", you must use $chr(35).

Try it: //echo -a $chr(35) # $chr(44) ,

Note that , is a bad example above, since it only has special meaning inside an identifier (like $nick(#,N))

Now... going back to the important word I used above, literally: these characters are special characters only when they appear literally in your code. If they come from input like $1-, they are not literals, and are not treated specially.

When you said "I can't tell people to use $chr(44)" you were once again confused. You need not tell people to use $chr(44).

Try it: //tokenize 32 a , b , c | echo -a $remove($1-,$chr(44))

The above will remove all commas from the text. Note that you cannot use the literal "," in the $remove, you will confuse mIRC syntactically.

This means you can't directly tell mIRC to do: $replaceIt(,)

But you can use a , when taken from a %variable or $1-:

//var %x = , | echo -a $replaceIt(%x)

Basically, your alias works fine (I still recommend using a regex). You only think it's broken because you're testing it incorrectly.

Hope that clarifies the issue. There are no problems with reading character input in mIRC, it all depends how you do it.

This still falls apart for me cause I can't think of a work around for every character mirc sees as special espically

Example:


Decided to wikipedia mirc scripting language too

mIRC Scripting lanugage Limitations

I'm guessing I'm running into the second limitation -.-

Yes, you are running into that limitation, and I told you how to get around it; escape the special characters instead of using them literally.

//tokenize 32 a $chr(124) b $chr(124) | echo -a $1-

Note that this limitation is not unique to mIRC. This is the same issue as in the regular expression syntax. For instance, you cannot have the regular expression matching [] without escaping the [] characters, since they have special meaning in regex syntax. The means for escaping in regex is \[, in mIRC, it's common to use $chr().

Yes, you're again using special characters (in this case pipes) literally in a command line.
See the difference when you do:


This is how mIRC will also behave when it processes input in remote scripts (where interpretation is (mostly) not literal as in command line).

That's a very confusing example. /set is allowed to use literals in this case, even though we said you can't. It can because it is only using one /, as opposed to two. Commands typed with one / in the editbox are not parsed by the script parser, so literals are okay.



Note the difference.

In the script editor, however, all commands are executed as if they were typed with //, regardless of how many /'s you use in your commands in an event/alias. If you understood the explanation above it should be clear as to why.

You're right of course.

My example is meant to show that when the input comes from - call it - an indirect source (meaning not from command line; in this case a pre-set variable, but it can also be $1- in a script event), that in those cases symbols are not interpreted as script syntax.

I'll try not to confuse people here. ;-)

Thanks everyone I finally got my head around it.

StrawberryKitty, there's nothing wrong with the code Horstl provides for you. With a little revamp of it, here is all you need to replace all the characters with the underscore as you've mentioned:This does exactly the same thing compared to your example of using $replace(), which takes longer and more bytes. Best yet, even in a sentence that consists of any of those characters will be replaced with the underscore. Other normal text won't be effected.

I'll suggest that you use a custom text event instead of the default one to display the result. A custom text event will look like this:You might want to cover the on action or notice event if needed.