Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ General ➜ Cannot add Inventory_Window_2 plugin. Or any plugin for that matter.
Cannot add Inventory_Window_2 plugin. Or any plugin for that matter.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by Atjohns97   (1 post)  Bio
Date Tue 17 Nov 2015 06:08 PM (UTC)

Amended on Tue 17 Nov 2015 07:47 PM (UTC) by Nick Gammon

Message
Okay, so recently I tried adding the Inventory_Window_2 plugin from here:(http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=9574)
and followed all the steps here, however when I go to add it, I get an output of: 


Compile error
Plugin: Inventory_Display (called from world: Aardwolf)
Immediate execution
[string "Plugin"]:492: invalid escape sequence near '"^('
Error context in script:
 488 :     for i,v in pairs (invT) do
 489 :       EnableTriggerGroup ("invdetails", true)
 490 :      repeat
 491 :       Send ( "invdetails " .. tostring (invT[i][1]) )
 492*:          line, wildcards = wait.regexp ("^(\{invdetails\})$")
 493 :          wait.time (1)
 494 :      until line == "{invdetails}"
 495 :     end
 496 :    end)  -- end of coroutine
[WARNING] C:\Users\Andrew\Desktop\Inventory_Window_2.xml
Line  321: Error parsing script (Cannot load)


I for the life of me can't get it to install or load in any way. On top of that no plugin at all will load. So I think it might be something in my settings, but I'm not sure.

I'm running the Aardwolf version of MUSHclient 4.98 on Windows 8.1.

Any help would be much appreciated!
Top
Posted by Fiendish   USA  (2,555 posts)  Bio   Global Moderator
Date Reply #1 on Tue 17 Nov 2015 06:35 PM (UTC)

Amended on Tue 17 Nov 2015 06:46 PM (UTC) by Fiendish

Message
It's not you. That plugin is in error.

Quote:
[string "Plugin"]:492: invalid escape sequence near '"^('
Error context in script:
492*: line, wildcards = wait.regexp ("^(\{invdetails\})$")

That's definitely an invalid Lua escape sequence that goes ignored by PUC-Rio Lua 5.1 but is flagged as invalid by LuaJIT (which gets bundled with the Aardwolf package instead of PUC-Rio Lua 5.1) because invalid escape sequences are often indications of secretly incorrect expression patterns.

You either want to change that line to:

line, wildcards = wait.regexp ("^(\\{invdetails\\})$")

or

line, wildcards = wait.regexp ("^({invdetails})$")

Depending on the original intent. I'm guessing probably the first one?

Quote:
On top of that no plugin at all will load.

That seems quite exceptional and unlikely. What other plugins did you try?
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #2 on Tue 17 Nov 2015 08:06 PM (UTC)

Amended on Tue 17 Nov 2015 08:07 PM (UTC) by Nick Gammon

Message
Fiendish said:

That's definitely an invalid Lua escape sequence that goes ignored by PUC-Rio Lua 5.1 ...


The Reference Manual seems silent on what is the effect of \x where x is not in their listed series of characters that "can" be used.

I would expect that \x where x does not have a defined effect would result in x, so that you don't have to remember whether to escape things, like single quotes inside a double-quote literal.

In particular:


      case '\\': {
        int c;
        next(ls);  /* do not save the `\' */
        switch (ls->current) {
          case 'a': c = '\a'; break;
          case 'b': c = '\b'; break;
          case 'f': c = '\f'; break;
          case 'n': c = '\n'; break;
          case 'r': c = '\r'; break;
          case 't': c = '\t'; break;
          case 'v': c = '\v'; break;
          case '\n':  /* go through */
          case '\r': save(ls, '\n'); inclinenumber(ls); continue;
          case EOZ: continue;  /* will raise an error next loop */
          default: {
            if (!isdigit(ls->current))
              save_and_next(ls);  /* handles \\, \", \', and \? */
            else {  /* \xxx */


The second-last line there appears to indicate that the "defined" behaviour (if you count what the source actually does as the defined behaviour) is to accept any "non-special" character after a backslash and treat it as the non-escaped version.

So, the escape sequence is not "ignored" (which implies it is omitted) but treated like I would expect: \x is x if x does not have another definition.



Plus I think it is naughty of LuaJIT to introduce a different behaviour to what the official source does.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Fiendish   USA  (2,555 posts)  Bio   Global Moderator
Date Reply #3 on Wed 18 Nov 2015 02:24 PM (UTC)
Message
Quote:
Plus I think it is naughty of LuaJIT to introduce a different behaviour to what the official source does.

Well, this behavior changed between PUC-Rio Lua 5.1 and 5.2, so they also decided that erroring on invalid sequences is the right thing to do.

Quote:
The Reference Manual seems silent on what is the effect of \x where x is not in their listed series of characters that "can" be used.
The reference manual is silent on a number of things that end up being dangerous in practice, like how to perform rounding when passing floats into string.format %i. (Which I think we just recently saw an instance of in the forum?)

Quote:
I would expect that \x where x does not have a defined effect would result in x, so that you don't have to remember whether to escape things

That's dangerous. It means you can accidentally and silently fail to escape something in your regex pattern, leading to an entirely different pattern. Better to be told that you've done something wrong so you can fix it right away instead of introducing a silent bug.
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #4 on Wed 18 Nov 2015 08:33 PM (UTC)
Message
Yes, but Lua regexps are escaped with "%" and not backslash, so that problem doesn't exist to a great extent.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Fiendish   USA  (2,555 posts)  Bio   Global Moderator
Date Reply #5 on Thu 19 Nov 2015 09:16 PM (UTC)

Amended on Thu 19 Nov 2015 09:18 PM (UTC) by Fiendish

Message
Quote:
Yes, but Lua regexps are escaped with "%" and not backslash

Lua "patterns" escape with %. Not quite the same.

Quote:
so that problem doesn't exist to a great extent.

Whaaaat?? That problem is exactly what caused OP to make this thread. The mentioned plugin has a regex with ambiguous intent and dubious functionality. Can you actually say what the correct fix is here? Can you even say if the plugin in its original form was working correctly because of this escape mistake? I can't. I can only guess.
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #6 on Thu 19 Nov 2015 09:56 PM (UTC)

Amended on Thu 19 Nov 2015 10:26 PM (UTC) by Fiendish

Message
Sure I can.


 492*:          line, wildcards = wait.regexp ("^(\{invdetails\})$")


The (unnecessary) backslash before the { and } should be treated as not being there. This is what Lua 5.1 does.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #7 on Thu 19 Nov 2015 09:57 PM (UTC)
Message
Quote:

That problem is exactly what caused OP to make this thread.


Your use of LuaJIT is what caused him to make the thread, not his string management. That is a side-effect.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Fiendish   USA  (2,555 posts)  Bio   Global Moderator
Date Reply #8 on Fri 20 Nov 2015 12:34 AM (UTC)

Amended on Fri 20 Nov 2015 12:35 AM (UTC) by Fiendish

Message
Nick Gammon said:

Sure I can.


 492*:          line, wildcards = wait.regexp ("^(\{invdetails\})$")


The (unnecessary) backslash before the { and } should be treated as not being there. This is what Lua 5.1 does.


Neither of us has any reason to believe that the author intended for that behavior given how it's written. All you know is how the engine interprets the string, but you have no idea if that interpretation is the proper one at all. In fact, I think it might be the wrong one. Curly braces are a special character in a regex pattern and should be escaped when intended to be literal, which means the slashes should be doubled, not ignored, because they are not unnecessary, because the curly braces are meant to be literal in the regex pattern not literal parts of the string that contains the regex pattern.

Nick Gammon said:

Quote:

That problem is exactly what caused OP to make this thread.


Your use of LuaJIT is what caused him to make the thread, not his string management. That is a side-effect.

LuaJIT (Lua 5.2, actually) is just making the error in the plugin apparent instead of silent. The plugin was in error from the start, but Lua 5.1 hid that, leading to potentially erroneous behavior instead of an error message.
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #9 on Fri 20 Nov 2015 04:44 AM (UTC)
Message
Fiendish said:

Curly braces are a special character in a regex pattern and should be escaped when intended to be literal, which means the slashes should be doubled, not ignored, because they are not unnecessary, because the curly braces are meant to be literal in the regex pattern not literal parts of the string that contains the regex pattern.


You are confusing PCRE regular expressions (where both backslashes and curly braces have meanings) and Lua regular expressions, where neither do.

http://www.gammon.com.au/scripts/doc.php?lua=string.find
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #10 on Fri 20 Nov 2015 04:54 AM (UTC)
Message
If you look at http://www.lua.org/manual/5.2/manual.html you will see no mention of it being an error to have a backslash followed by one of the non-explicit escaped characters. Indeed it says:

Quote:

Any byte in a literal string not explicitly affected by the previous rules represents itself.


Thus you could argue that under that "default" rule that "\{" should actually represent "\{" (itself), and not raise an error.

I cannot see any reference to this change in behaviour in the section "Incompatibilities with the Previous Version".

Note to script-writers: I am not supporting Lua 5.2, as they made many changes to many things, include the way environments work. Things like serialization which use setfenv will not work. Thus I have stuck with Lua 5.1.

From the reference (link above):

Quote:

8.2 – Changes in the Libraries

Function module is deprecated. It is easy to set up a module with regular Lua code. Modules are not expected to set global variables.
Functions setfenv and getfenv were removed, because of the changes in environments.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Fiendish   USA  (2,555 posts)  Bio   Global Moderator
Date Reply #11 on Fri 20 Nov 2015 10:24 AM (UTC)

Amended on Fri 20 Nov 2015 10:26 AM (UTC) by Fiendish

Message
Nick Gammon said:

Fiendish said:

Curly braces are a special character in a regex pattern and should be escaped when intended to be literal, which means the slashes should be doubled, not ignored, because they are not unnecessary, because the curly braces are meant to be literal in the regex pattern not literal parts of the string that contains the regex pattern.


You are confusing PCRE regular expressions (where both backslashes and curly braces have meanings) and Lua regular expressions, where neither do.

http://www.gammon.com.au/scripts/doc.php?lua=string.find


Not at all! Be clear that I am not talking about string.find or any other string.foo. Lua's string library does not use regular expressions; it uses Lua simplified patterns. There are things you can do with regular expressions that you can't do with Lua's patterns.

MUSHclient does, however, use PCRE matching for triggers and also includes Lua PCRE. When dealing with actual PCRE regular expressions (like with wait.regex for example!) it is very very important to make sure that the patterns are expressed accurately and unambiguously. OPs plugin fails to do that, and Lua 5.1 just silently trucks along without revealing the author's mistake.

The problem is that both PCRE and Lua strings both have their own separate literal escape steps. OP's plugin seemingly intends to escape the braces at the PCRE level, not the Lua string level, and it failed at this. We should ask first "Why would the author try to escape curly braces in a string?" The answer is that he wasn't. He was trying to escape curly braces in the next-level-down PCRE expression. Stripping the slashes would thus violate the author's actual intent and produce a PCRE that matches something unintended.


Quote:
If you look at http://www.lua.org/manual/5.2/manual.html you will see no mention of it being an error to have a backslash followed by one of the non-explicit escaped characters.

That's true. I chalk that up to a documentation error, because accurate documentation is hard. The interpreter's behavior did change between 5.1 and 5.2, though (You can verify this at http://www.lua.org/cgi-bin/demo and http://trylua.org/). And for the above stated reasons, I believe the particular change to be a very good one.
The difference should of course have been documented, but you're right that it isn't.

Quote:
Note to script-writers: I am not supporting Lua 5.2

Good. I don't think anyone wants that as it would break too much good code.
Note, however, that OP's particular issue is not breaking good code but rather suddenly highlighting bad code.
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #12 on Fri 20 Nov 2015 09:11 PM (UTC)

Amended on Fri 20 Nov 2015 09:12 PM (UTC) by Nick Gammon

Message
Oops. You are right about it being a PCRE regexp. I got the idea into my head it was a string.find and once it was there it stayed there. :)

You are right about the possible confusion with the backslashes in a PCRE regexp, which are the devil to get right in Lua, particularly if you are doing them in the "Send" box where you need four backslashes in a row to get a single backslash into the PCRE engine.

Quote:

I chalk that up to a documentation error, because accurate documentation is hard.


Indeed, as documentation is often done after the event, and quite probably by someone other than the coder. Still, I call it a bug when the code and the documentation don't match. If you documented the "+" symbol to do subtraction when it really does addition, perhaps the code is wrong and not the documentation?

Personally, these days, I update the documentation as soon as I have made a code change (and tested it).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

38,693 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home