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.
