[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Using Lua to replace C
- From: Sean Conner <sean@...>
- Date: Thu, 24 Feb 2011 16:43:59 -0500
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
And if you are really concerned about reliability and security, then you
should also lobby to remove LD_LIBRARY_PATH support from Unix 8-)