Re: Using Lua to replace C

[Sean Conner <sean@...>]

It was thus said that the Great Reuben Thomas once stated:
> 
> 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. 

  Can you explain why it's important to remove LUA_INIT, LUA_PATH and
LUA_CPATH?  I personally find them very useful, and in fact, I'm using
LUA_PATH and LUA_CPATH for a project at work (a testing framework for an
application we're writing) since different testers have different top level
directories for their copies of the source code repository (example:  I tend
to have checked out the code under $HOME/source, while another person puts
it under $HOME/wc/ ("wc" I suppose stands for "work code")).  Using LUA_PATH
and LUA_CPATH we can point a default make of Lua to our respective layouts
(since the application run on Solaris and we all share a single Solaris
development box).

  And if you are really concerned about reliability and security, then you
should also lobby to remove LD_LIBRARY_PATH support from Unix 8-)

  -spc