Re: Using Lua to replace C

[Reuben Thomas <rrt@...>]

Luiz Henrique de Figueiredo <lhf <at> tecgraf.puc-rio.br> writes:

> 
> > 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.
> 
> Really? If you wrap lua with
> 	exec env LUA_INIT= LUA_PATH= LUA_CPATH= lua $*
> then even hash-bang scripts will work if your wrapper appears first in your
> shell path.
> 
> Or am I missing something?

I'm saying that the problem is precisely that a wrapper is needed.

To reply to various messages in this thread all at once, and hopefully clarify 
my position:

1. I believe that LUA_PATH & LUA_CPATH are valuable. Most scripting languages 
have some equivalent; it's a handy way to specify non-standard library 
locations. (This can be done with LUA_INIT, of course, but I think the extra 
simplification is worth it.) One might debate whether it's necessary to have 
LUA_CPATH as well as LUA_PATH, but that's as far as I'd go.

2. To run a script without allowing the user to alter the search paths, for 
whatever reason, should be possible without needing a wrapper or extra 
environment on the command-line. Again, most scripting languages have some way 
of doing this.

Hence, I'd like a switch to stop the interpreter (lua.c) from querying the 
environment variables LUA_INIT, LUA_PATH and LUA_CPATH. I submit that this is 
sufficiently important and common (and easy to get wrong) that it deserves a 
switch.