Most of Lua's standard libraries are available, although some of them may only be available partially or as re-implementations, meaning behavior may differ slightly. Please see the Lua 5.3 manual for documentation on the standard libraries.
Descriptions of “re-implementations” are based on OpenOS. Other custom operating system may have different details.
This page tries to list all differences to these standard libraries.
The original functions from the base library are available with the following differences.
collectgarbage is not available.dofile and loadfile have been reimplemented to load files from mounted file system components (they use the filesystem API / reimplemented io library).load can only be used to load text, no binary/compiled code by default. Note that bytecode loading can be enabled in the config, but is really not recommended, since it is a major security risk.print, io.write, and io.stdout:write, and term.write all push strings through stdout, which in most circumstances means gpu rendered, i.e. printed to the screen.
The original functions from the coroutine library are available with no observable differences.
Note that the coroutine.resume and coroutine.yield implementations exposed to user code are wrappers that take care of aborting code that does not yield after a certain time (see config), and to allow differentiating system yields from user yields (system yields “bubble”, for example this is used for the shutdown command and component API calls). This should not be noticeable from user code, however. If it is, it should be considered a bug.
The package module got a reimplementation for OpenComputers. It should operate the same as the original, but is lacking the following functions:
package.config is missing and not used.package.cpath is missing and not used.package.loadlib is not implementedThe latter two are missing because it is impossible to load C code in OpenComputers .
The original functions from the string library are available without alterations.
Note that the functions of the GPU API work on UTF-8 strings, and, by extension, so does term.write and print. To help you work with UTF-8 strings, there is an additional library, the Unicode API.
The original functions from the table library are available without alteration.
The original functions from the math library are available with minor alterations.
math.random uses a separate java.util.Random instance for each Lua state / computer.math.randomseed is applied to that instance.
The original functions from the bit32 library are available without alteration.
The original functions from the io library have been reimplemented for the most part, and work on mounted filesystem components. Standard input is read by io.read (as well as term.read and io.stdin:read). Standard ouput is written to by io.write (as well as term.write, io.stdout:write, and print). Standard error is written to by io.stderr:write.
For the most part these should be functionally equivalent to the standard Lua implementation. They may return error strings that differ from vanilla Lua, though, but since that uses C library errors for the most part, which are platform dependent, it's not a very good idea to use these for program logic anyway.
io.open(path,mode) does not support the + modes, i.e. it only supports r, w, a, rb, wb and ab. Binary mode is always used. Note that io.open() returns a buffered stream with smart api such as read("*a") to read the whole file, or io.read("*l") to read a single line. Note that a buffered stream f:read(1) will return 1 unicode-aware character. Contrast to this is filesystem.open, whose raw handle f:read(1) reads a single byte.
path is a relative or absolute path to a file you want to open.
mode can be nil or a string. nil defaults to “r”. “b” is ignored, all buffered streams are unicode aware. If you need to read byte by byte, use a raw file handle via filesystem.open
io.open(path, "r") is equivalent to io.open(path), which opens a file in read-only mode.io.open(path, "w") truncates all contents from a file and opens it in write-mode.io.open(path, "a") opens a file in write-mode putting the file handle position at the end of the file, meaning the next write will append to the end of the file.io.stdin reads data from the emulated stdin, which defaults to the user input in the openos shell. Note that io.read() is short hand for io.stdin:read(), they resolve to exactly the same operation.io.stdin:read() -- read from std in io.read() -- also read from std in
io.stdout writes data to the emulated stdout, which defaults to render on the gpu. Note that io.write() is short hand for io.stdout:write(), they resolve to exactly the same operation.io.stdout:write("write to stdout") io.write("also write to stdout")
io.stderr writes data to the emulated stderr, which defaults to render on the gpu, but tries to do so in a red color, if supported by the primary GPU and Screen. There is no short hand for using stderr like there is for stdin and stdout.io.stderr:write("error text to stderr")
The original functions from the os library have been partially reimplemented.
os.clock has been reimplemented to return the approximate CPU time, meaning the time the computer has actually been running in an executor thread. This is not the same as the time the computer has been running, for that see computer.uptime.os.date has been reimplemented to use ingame time and supports most formats.os.execute has been reimplemented to start programs from a mounted filesystem via shell.execute. The specified string is parsed the same as commands entered in the shell.os.exit throws an error to try and terminate the current coroutine.os.setenv is added to set shell variables from Lua.os.remove is an alias for filesystem.remove.os.rename is an alias for filesystem.rename.os.setlocale is not available.os.time has been reimplemented to return the ingame time since the world has been created.1000/60/60 (since there are 24000 ticks in a day) and subtract 6000. This offset of 6000 is not arbitrary, it ensures that 6 o'clock AM is actually that. Minecraft somehow thinks six o'clock in the morning is zero - probably because that's “when” a new game starts…os.tmpname has been reimplemented to generate an unused name in the /tmp mount.
One additional function has been added:
- os.sleep(seconds: number) which allows pausing a script for the specified amount of time. Note that signals will still be processed by event handlers while the sleep is active, i.e. you cannot pull signals that were accumulated during the sleep after it ended, since no signals will remain in the queue (or at least not all of them).
Some new functions that kind of fall into this category are available in the computer API.
Only debug.traceback and debug.getinfo (since 1.5.9), which is limited only to passive info, are implemented.