lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Thu, Feb 24, 2011 at 14:43, Sean Conner <sean@conman.org> wrote:
> 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
>
>
>

I've also moved from C programs with Lua embedded to Lua scripts with
C bindings. It's very nice, having nearly all of the program logic in
Lua, just writing a quick C binding for any library I need (or more
often the binding already exists!)

The lack of LUA_INIT does bother me a bit. I find myself starting each
script with:
#!/usr/bin/env lua
local init = os.getenv("LUA_INIT"); if init then
	if init:sub(1,1) == '@' then dofile(init:sub(2)) else loadstring(init)() end
end

This allows me to have a generic init script which adds some paths to
package.path and package.cpath. It would be nice if it did this
automatically though, maybe by some switch to the interpreter that I
could just add to the #! line.

-- 
Sent from my toaster.