Hi, I've just removed the last C file from the "lua" branch of GNU Zile (a cut-down Emacs clone). https://savannah.gnu.org/projects/zile/ Converting Zile into Lua incrementally relied on my simple clue framework: http://luaforge.net/projects/clue of which I will shortly make a new release which adds full backtraces to Lua calls by stealing code from lua.c. (Of course, clue is not used in the final, pure Lua, result, but it was essential to having a code base that was functional and testable the whole time.) Since Zile is written using only POSIX APIs, including curses, I used luaposix (and in the process added some important functionality, currently unreleased, including getopt and signals), and lcurses (of which I have released a new version with the improvements I needed). The standard lua.c Lua interpreter has two problems, one of which I can live with (the way it puts command-line arguments on the stack, thus limiting the number of arguments; being an interactive editor, Zile is rarely used with very long command lines), and secondly, its inability to force default settings for LUA_INIT, LUA_PATH and LUA_CPATH on the command line. I can work around this with an extra level of script, but it means that I can't easily start Zile from a hash-bang script. One could write something like: #!/usr/bin/env lua -e "LUA_INIT,LUA_PATH,LUA_CPATH=nil" but this could run into problems on some kernels with length limits on the command-line for hash bang lines. I attach a patch for 5.1.4 which adds a -t flag (I couldn't think of a better letter, as one would expect -d to debug; I was thinking of t for taint) which, since the reading of the environment variables happens in loadlib.c, and since (un)setenv is not portable, simply overwrites loadlib.path and loadlib.cpath with the default values. This is, in my view, important to fix, as otherwise it's hard to write reliable/secure portable single-file Lua programs. On the other hand, it's the only major obstacle to replacing C with Lua for portable POSIX programs (I mean, of course, programming obstacle, I'm not talking about performance). Even in my naive translation, I've reduced the code base by about 26%, and debugging is now much faster and easier. Because of Lua's wonderful portability, portability of the code is not, in principle, reduced at all, although in practice it is somewhat for now, since luaposix is not built using gnulib, and thus relies rather more on the underlying POSIX implementation. I aim to fix this. -- http://rrt.sc3d.org
Attachment:
lua-5.1.4-no_init_or_paths.patch
Description: Binary data