|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
on ^*:TEXT:*:*:{
var %s = $1-
}If $1- contains "" (literally two quotation characters and nothing else), %s is set to empty. Is there a way to set a local variable to "" or is it just not possible?
|
|
|
|
|
Joined: Nov 2006
Posts: 1,559
Hoopy frood
|
|
Hoopy frood
Joined: Nov 2006
Posts: 1,559 |
At least set -ln should do the trick - unfortunately it does not.
I really think it should, "treat value as plain text" should not have a loophole of such kind. I believe this can be regarded as a bug.
|
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
Since mIRC variables are untyped, I thought the purpose of -n was to declare a typed variable (type: text). For instance: alias x {
set -ln %x 00
if (%x == 0) echo -s -> LN 0 (this should NOT appear)
if (%x == 00) echo -s -> LN 00 (this should appear)
set -l %x 00
if (%x == 0) echo -s -> L 0 (this should appear)
if (%x == 00) echo -s -> L 00 (this should appear)
}But when I tried this, all 4 echo statements worked. So I guess -n doesn't work that way either. Does anyone know exactly what -n does do? Anyway, regarding the "" issue, I tried manually setting a global variable named %zzz to "" in the script editor's variables tab, but //echo $+(A,%zzz,A) returned AA. So either variables can't contain "" by design or the bug also affects variable declarations which mIRC scoops up from the script editor variables tab. Anybody know for sure?
|
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
Basically -n prevents the automatic arithmetic behaviour caused by setting a variable to a value of the format <number> <arithmetic-operator> <number>. eg. Compare the following: //set -l %moo 1 + 1 | echo -a Normal: %moo
//set -ln %moo 1 + 1 | echo -a Using -n switch: %moo It really should prevent the "" behaviour as well IMO so you should post this in either Bug Reports or Feature Suggestions.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
|
Joined: Aug 2006
Posts: 183
Vogon poet
|
|
Vogon poet
Joined: Aug 2006
Posts: 183 |
Unless the variable MUST be "" for some reason, I'd suggest setting it to something else and then replacing that something else into "" using $replace.
For example (semi-psudeo-code, NOT real code)
var %a ~~
say These are double quotes! $replace(~~ with "")
That should get around it. Though I agree this seems to be a bug.
Yar
|
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
For variables accepting $1- inside INPUT/ACTION/TEXT/CHAT, yes, it must (and should) be able to cope with whatever local or remote users/bots spew.
Character replacement is not a solution because there is no character you can replace " with that cannot also be sent by the typist/bot. In other words, if "" becomes ~~, your ensuing code then cannot tell whether the user really sent "", or ~~ itself.
The only workaround I have figured out is var %s = $qt($1-). With this, $null stays $null (because a null string inside $qt() will cause %s to eat $qt()'s quotes). But " becomes """, "" becomes """", "a" becomes ""a"", etc. You can then refer to %s at all times with $left($right(%s,-1),-1). Of course, this makes things unnecessarily complex, especially when doing heavy string parsing.
(SM, thanks for explaining the true purpose of -n.)
|
|
|
|
|
Joined: May 2012
Posts: 5
Nutrimatic drinks dispenser
|
|
Nutrimatic drinks dispenser
Joined: May 2012
Posts: 5 |
alias test {
var %s $+($1,\)
return $regsubex(%s,/^(.*)\\$/,\1)
}
//echo -a $test("") This will return "" Let me know if it doesn't work as you intend it to.
|
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
Thanks, I appreciate this, but alas no, it does not solve the problem. Your version of what I'm doing would entail this: alias test {
var %s $+($1,\)
return $regsubex(%s,/^(.*)\\$/,\1)
}
alias testtwo {
var %s = $test("")
; lots of my code here which must work with %s
echo %s
}The problem is that mIRC %variables cannot themselves physically contain ""
|
|
|
|
|
Joined: May 2012
Posts: 5
Nutrimatic drinks dispenser
|
|
Nutrimatic drinks dispenser
Joined: May 2012
Posts: 5 |
Why exactly is it a problem? There are various non-tedious ways around it. It's not a bug, it's mSL's interpretation. One simple alias and it's resolved, even if you want to test for an empty string. Sorry if I'm missing it here.
Need help? Feel free to add me on msn or come to the server I listed.
|
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
Look at it this way. on *:TEXT:*:*:{
var %s $+($1-,\)
; say i need to parse %s 50 times here -- why doesn't matter, just say I do.
; each time i do, i have to account for the fact there's an \ at the end --
; which means either 50 instances of $left(%s,-1) ... or if I'm doing regexp
; based parsing, 50 regexps that are now more complex.
echo $target $+(<,$nick,>) $regsubex(%s,/^(.*)\\$/,\1)
haltdef
}The reason I brought up this issue isn't that it's difficult to work around on principle. I brought it up because it becomes difficult to work around in practice, when volume is factored in. Imagine you want all your events, and all your aliases, everywhere, to not eat "" in case they receive it from some IRC user/bot. In that case, you have to implement the workaround in every event, and in every alias, everywhere. And I couldn't just use your test alias, like this: alias myparser {
var %s = $test($1-)
; code here
}Because here, var %s = would just eat the "" and leave me with $null again. So unless I'm missing something, yes, every variable everywhere which is populated with input from a server would need to have special handling hardcoded for it, to work around this issue.
|
|
|
|
|
Joined: May 2012
Posts: 5
Nutrimatic drinks dispenser
|
|
Nutrimatic drinks dispenser
Joined: May 2012
Posts: 5 |
Unfortunately, that is mSL. It's not a bug, it's a limitation. Although you can script an alias (or two for clarification) to work around it, I do understand your point. If they do update how mSL interprets "empty strings," I'm all for it.
On another note, it would be pretty fun to script a "string" alias that would have various properties to read empty strings, add/remove trailing whitespace, etc.
Need help? Feel free to add me on msn or come to the server I listed.
|
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
It's not a limitation it's a feature, this has been added on purpose in the past.
You cannot workaround it with %variable and alias easily.
That won't be changed cause "it would break script©" but nowadays, it seems the feature isn't used anymore and is rather annoying instead of being useful.
As said, it should be reported, /set -n should prevent this.
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
Joined: May 2012
Posts: 5
Nutrimatic drinks dispenser
|
|
Nutrimatic drinks dispenser
Joined: May 2012
Posts: 5 |
"it's not a limitation, it's a feature"
I would agree, but I suppose it depends on how you look at it. As for working around it easily, I agree. But that largely depends on what you're trying to accomplish.
Need help? Feel free to add me on msn or come to the server I listed.
|
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
Well, here it doesn't depend on how you look at it, it depends on if you can find it in the www.mirc.com/versions.txt which regroup pretty much every change made to mIRC and from mIRC 4.5: 70.Can now set a string variable to an empty string with "".
eg. set %name "" or %s = ""
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
Joined: May 2012
Posts: 5
Nutrimatic drinks dispenser
|
|
Nutrimatic drinks dispenser
Joined: May 2012
Posts: 5 |
It still depends on how you look at it. If you can't accomplish something simply due to a "feature," and mIRC doesn't provide a simple workaround, it is a limitation—even if, in most cases, it's not a problem. Besides, a feature can be a limitation.
Now, generally one should be able to use a binary variable, I believe. Have you tried this, pishposh?
Need help? Feel free to add me on msn or come to the server I listed.
|
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
Yes, I had considered binvars. However, whether %variable\ kludging or &binvars, you're still talking about re-writing generous proportions of the variable handling and parsing in all events and aliases that deal with server input. So, it's still not as ideal as a workaround that just allowed you to force literal "" into %variables in the first place.
|
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
Call that a limitation if you want, it's not important.
mIRC does provide a lot of simple workaround (any other storage's method), they are just not satisfying, people want to use %variables.
I personnaly think the behavior may have been a good thing in the past but nowadays I think it should be removed, I've never seen any script using it, and people either use $null as a value or /unset
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
/set -n can allow for "", but it wouldn't change the underlying problem that pishposh pointed out: You can directly write your variable in the variables tab like so: But you still won't be able to pull it out. This is because mIRC treats "" as a special value. I'm not really sure why it does this, but it does. Until (if) this behaviour is changed, there's no way for a variable to contain "" while still being usable. Your best bet would be to NOT use mIRC's variables for storing arbitrary data. Given that %variables are just a convenience shorthand for using /writeini and $readini, nothing is stopping you from using those two commands on your own for your arbitrary data format, and not dealing with mIRC's variable limitations. So rather than trying to find a workaround to make variables work the way you want, you can simply avoid them in this case. You don't really need them.
alias mydata { return $readini(myfile.ini,section,$1) }
//echo -a $mydata(myvar)
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Aug 2006
Posts: 167
Vogon poet
|
|
OP
Vogon poet
Joined: Aug 2006
Posts: 167 |
"Variables. They're just a convenience over disk writes. You really don't need them." I'm putting that in my paraphrased quotes file.  Well, despite any merits or disadvantages of this particular workaround, I can already name one application where every TEXT/ACTION/CHAT/INPUT event being written to disk would count as positively verboten: among the encryption scripts crowd.
|
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
Character replacement is not a solution because there is no character you can replace " with that cannot also be sent by the typist/bot. Yes there is: $crlf (I know that's two chars, but it'll work)
|
|
|
|
|
