![]() (This is no longer a problem with Lua 5.2, which does sanity checks first.)įor Windows GUI subsystem, os.execute can be irritating, and io.popen simply won't work - cross-platform extension libraries are available in this case.Įrror log says: ERROR::4: :1: unfinished string near ''Ĭhanged command seperator from to something elseĮrror log says: ERROR::1: attempt to call global 'run' (a nil value) Likewise, os.time can actually crash Lua if passed non-compatible format specifiers. Be careful of os.tmpname because it does not return a full path on Windows (prefix with the value of the TMP environment variable together with a backslash first.) os.clock is implemented very differently on Windows. Use the "rb" specifier with io.open if you need compatibility with Windows binary I/O. Lua depends more directly on the system's C runtime libraries than most scripting languages so you have to appreciate platform differences. It is therefore easier to do a local user install of Lua on Windows, but Lua respects the environment variables LUA_PATH and LUA_CPATH. As a general rule, try to use this when building paths.Ī big difference between the Windows and Unix builds is that the default package.path is based on the location of the Windows executable, whereas on Unix it is based on /usr/local/share/lua/5.1. nfig is a string where the first 'character' is the directory separator so nfig:sub(1,1) is either a slash or a backslash. Here, 'Unix' stands for any POSIX-like operating system such as Linux, Mac OS X, Solaris, etc. *nix file paths in the past I did use a check on, I think on one C array index into the config char array for '\\' or '/' - though I think a better solution was found subsequently.Īh, ha - yes - see the nfig variable - that is the thing, from the Lua Unofficial FAQ: 1.40 Compatibility issues between Windows and Unix? I recall this because when I fixed up the (internal to) a handling of Windows vs. That hasn't been my somewhat limited experience - IIRC there is a configuration setting somewhere in the lua stuff that contains a 4 character array which holds the compiled in settings for, amongst other thing, the wildcard character in package names and the directory separator. \a perhaps - so LUA_DEFAULT_PATH ought to have been. Remember if debugging this the on-screen message will reproduce a path that has gone through both I think \\ to \ un-escapings so should look like a proper, real Windows path on-screen - which would be \a in the case given - which is probably also wrong and should have been. The original error at the top of the topic is because LUA_DEFAULT_PATH is empty at the time it is used on Windows! ![]() This immediately seems a bit dodgy because A to D are all wrong for Windows, for instance A should be ".\\\\src\\\\mudlet-lua\\\\lua\\\\a" but the others need run-time replacements of / to \\\\ in both the literal strings AND the variables that are included. Path = LUA_DEFAULT_PATH "/a" // postMessage(e.c_str()) Finally try loading from LUA_DEFAULT_PATH MpHost->postMessage(" - Mudlet-lua API
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |