invalid escape sequence near ''$'

I upgraded our linux Iguana instance from 5.5.3 to 5.6.11 . Upon doing so the channels would not start due to an error in the node script on line 48. The error reads ” invalid escape sequence near ”$’ “…

function trimTrailingDollar(str)
if str:find(‘$\$’) == str:len() then
–remove trailing $ if there
str = str:sub(1, -2)
end
return str
end

…Why did the upgrade break this and what was your solution? Thank you!

Attachments:

You must be logged in to view attached files.

a magic character? http://www.lua.org/pil/20.2.html just a thought…

Looks like a fixed bug to me. The pattern syntax for the string.find() dollar sign search in your example is wrong. It should be “\$$” if you’re looking for a dollar sign at the end of the string; \$ represents a literal dollar sign and $ is a magic character representing the end of the string.

Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

Interesting… out of the office currently but I think we changed the version of Lua used in a major release from 5.5 to 5.6.

Looks like the new version is less tolerant of the syntax error.

Reminds me of a time we had a large customer do a big upgrade and it turned out many of their vmd files were using a undocumented incorrect call into the Python regex library that happened to return false. In the new version of python the same undocumented call returned true – which broke all their code.

It’s not a bad idea to upgrade periodically to catch problems like this early so they don’t stay in there and propagate. It’s analogous to companies that got frozen into a bunch of IE6 bugs with some of their apps which made upgrading to newer modern browsers difficult.

Assuming this is the problem…

Eliot – I think you are right that the upgraded LUA is why this has become an issue. Looks like they are trying to keep us more honest/true with the code.

Jeff – the (‘\$$’) produces the same error but I’m thinking (‘$%$’) might work (lev).

(funny part is that we don’t even use this piece of the node script but it just bugs me that bad code is out there and one day it could come back to bite me if I just comment it out or cut some corner now.)

I originally tested the pattern ‘\$$’ with ScITE (a handy tool for playing with Lua) and got the expected results.

I’ve since re-tested with Iguana 5.6.9 on Windows 64bit, and got . . . the expected results.

I then tested with Iguana 5.6.11 on Ubuntu, and got . . . AN ERROR. Uh oh.

So I tested with Iguana 5.6.11 on Windows XP and got . . . the expected results.

Finally, I went back to Windows 7 64bit and upgraded it to Iguana 5.6.11 and got . . . the expected results.

So, the fact that you’re on Linux may have something to do with it. Looks like an official support ticket is in order 🙁

Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

Personally, I prefer a less ambitious method:

function main()
local str=’abcd$’
trace(str:trimTrailingDollar())
end

function string.trimTrailingDollar(self)
if self:sub(-1) == ‘$’ then
return self:sub(1, -2)
end
return self
end

Jeff – I think you are on to the root issue at hand. The system runs on CentOS. Thank you for your detective skills!

lev – I think your code may need to be the solution for all of our linux iguana instances. Thank you for your code.

I’m going to get with support about this and if you are interested check back as I’ll be sure to post any new info about this issue here.

Thank you Chris, I am happy that you like my suggestion. Being extremely lazy, I prefer to call string.sub() and let Lua to count the bits, rather than do it myself 🙂

Lev, has a bug report been created for the difference in string.find()’s behavior between Windows and Linux? I know Chris has a solution, but I think the original issue should still be addressed. It’s not a serious bug, but it’s still a bug.

Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

Chris is it 64 bit Linux? If so then I think the likely cause of the difference in behavior is because that platform is using the Lua JIT 2.0 version of Lua.

yes it is 64bit.

Okay mystery solved then. I think we’re likely to shift this back to using the same version of Lua as other platforms. 64 bit Linux was the only platform we could get Lua JIT 2.0 to work on. I don’t think it’s worth the hassle.

We could roll back to using the same version of Lua we use on Windows and 32 bit Linux and then the behavior will be consistent across all platforms.

See:
http://help.interfaceware.com/forums/topic/iguana-5-6-12-released