Zugg Software :: View topic - [2.27] Using Wildcards in dbvars that are part of trigger patterns.

Adept Joined: 27 May 2008 Posts: 299

I have

#TRIGGER {^{%%dbkeys(@dbvar)}$}

#VAR dbvar {Test (%w).=blah|Test 2 (%w).=blah}

If output is..

Test string.

My trigger matches %1 = string Which it should.

However, if output is...

Test 2 string.

My trigger matches %2 = string Which it shouldn't. It should still be %1.

It does this due to that being the 2nd key in the var that has a wildcard, for instance if I were to make it

#VAR dbvar {Test (%w).=blah|Test 2.=blah|Test 2 (%w).=blah}

With output of

Test 2 string.

Then I would still get %2 = string

But if I had

#VAR dbvar {Test (%w).=blah|Test 1 (%w).=blah|Test 2 (%w).=blah}

with output of

Test 2 string.

Then %3 = string

This obviously isn't how it should work.

Posted: Fri Jun 13, 2008 1:01 am

Not a bug if you look at what the parser would actually be doing to expand that into regex (which all triggers do i believe).

Dbkeys would output a string list

ie, your pattern would be "Test (%w).|Test 2.|Test 2 (%w)."

which would change to

"Test (\w)\.|Test 2\.|Test 2 (\w)\."

Which would match "Test 2 string." to the third option, and the third option has the second capture group (i don't know what you'd call it if you were that tarzan guy from XKCD that knows regular expressions, so bear with me :P)

Second capture group is %2

Regex has always worked this way in z/cmud as far as i know.

Similarly, (?:(\d+),){1,3} will only capture to %1 iirc, no matter how many numbers you seperate by commas

Posted: Fri Jun 13, 2008 1:10 am

Your assumption's incorrect. This isn't how regexes work. Try this:

#regex {(?:something (\w+) something|blah (\w+) blah)} {#say First param is: %1;#say Second param is: %2}
#say something hmm something
#say %cr
#say blah hmm blah

Params are numbered based on where their leftmost bracket opens, regardless of whether or not that param's actually used as part of the match. In fact, that'll probably make your dbvar quite unreliable as a pattern, because it's sorted before it's made into a pattern, leaving you with no idea which param corresponds to which key. Depending on what you're trying to do, there might be a better method.

EDIT: Bah, ninja'd. I actually have that regex tshirt, alluran :P And a few from Dr McNinja.

Adept Joined: 27 May 2008 Posts: 299

so I fixed my issue above... what Im doing is simply this in my trigger

#TRIGGER {^{%%dbkeys(@dbvar)}$} {#say %db(@dbvar,%replace(%trigger,%1%2%3%4%5%6%7%8%9%10,"(%w)"))}

This is alittle cludgy but it gets the job done, and there shouldnt ever be a case as to where the captured word is higher than %10.

My next issue is...

When I try to add a key to a dbvar like so

#VAR dbvar {Test (%w).=blah|Test 2 (%w).=blah|(%w) 3 string.=blah}

and then the var compiles and I come back and look at it I end up with this

#VAR dbvar {Test (%w).=blah|Test 2 (%w).=blah|(%w)=|3 string.=blah}

It basicly strips the (%w) and moves it to a seperate key, which is bad cause then it will match any single word line using the above trigger.

Posted: Fri Jun 13, 2008 4:52 pm

It's not actually moving (%w) to a separate key, it's moving %w to a separate key and stripping the brackets (), which I think it the key to understanding this problem. The root of it, I think, is that () characters are special characters in CMUD that delimit expressions. CMUD is doing some kind of expression parsing on the third key that it's not doing on the other two (perhaps because the brackets () are at the start of the key rather than after some text) which is screwing up the parsing.

I imagine there's some kind of subtle bug involved here (because CMUD probably shouldn't be magically creating four keys when you only have two |s in there, and because quoting the brackets with ~ doesn't seem to help, and because it only does it to that one key). But it's quite obscure and it's pretty easy to work round:

#addkey somevar "Test (%w)." "blah"
#addkey somevar "Test 2 (%w)." "blah"
#addkey somevar "(%w) 3 string." "blah"

Really, you should get into the habit of using "" around anything you want to be a literal string, especially if it contains special characters.

Adept Joined: 27 May 2008 Posts: 299

You are correct. It only happens when the wildcard is at the start of the string.

The issue I have with using qoutes is the only way I add things to this var is via a command imput trigger or manually thru the PE.

my trigger looks like this

#TRIGGER {addvar ~{(*)~} ~{(*)~}} {#ADDKEY dbvar %1 %2}

Usually if there is a wildcard involved I add it manually. So should I add "(%w) 3 string." as the literal key, including the qoutes?

This becomes an issue later when im trying to pull the value for the key if so. Cause then I have to add quotes to the start and end of %trigger before I can match it back to the keys in the dbvar.

Posted: Sat Jun 14, 2008 7:04 am

try #addkey dbvar {%1} {%2}

Posted: Sat Jun 14, 2008 10:58 am

You don't need to add quotes to the start and end of %trigger, or you shouldn't need to anyway. The quotes aren't actually part of the string, they just show CMUD what's a string and what isn't. %trigger's already a literal string and shouldn't be parsed further.

Is your addvar thing actually a trigger, or is it an oninput trigger? If it's the latter, you might actually find it easier to use an alias. Aliases allow params to be grouped with {} or "" like normal CMUD commands do (so somealias {hello there} means %1="hello there") so you can use "" around your strings to make sure they get sent to the parser intact.

Posted: Mon Jun 16, 2008 4:49 pm

The problem causing this is when CMUD tries to parse the old syntax:

#VAR varname {a|b|c}

to create a string list, it requires the character after the | to be an alpha-numeric character. You shouldn't be creating database variables using that "inline" syntax anymore. You need to use #ADDKEY as mentioned in this thread to properly create a database variable. This will also give you a much faster database variable since #ADDKEY creates entries directly in the hash table, whereas your #VAR syntax requires converting from a string to a hash table, and will be slower.

Adept Joined: 27 May 2008 Posts: 299

I actually am using #ADDKEY. As I stated above...

Posted: Mon Jun 16, 2008 5:23 pm

In your #ONINPUT trigger, make sure you also use #NOINPUT and set the trigger to be a Prompt Trigger instead of a Newline trigger and then you can intercept the command line before CMUD tries to parse it.

But I was able to reproduce the problem that you mentioned by pasting "(%w) test here." into the Package Editor (without the quotes of course). So yes, there does seem to be a bug here. I've added it to the bug list.

Adept Joined: 27 May 2008 Posts: 299

Thank you. I think the bug is the root of my issues and if that were fixed I could handle the work around for making it work as I was intending it to.

Posted: Tue Jun 17, 2008 8:54 pm

I believe I have the problem with adding "(%w) test here." to the database variable fixed for v2.28. There was an old compatibility syntax where nested lists used to use parenthesis, and it was getting confused by that code in your case because the key started with a (.