lua-users home
lua-l archive

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

On 22 September 2011 01:39, David Manura <> wrote:
> On Tue, Sep 20, 2011 at 7:26 AM, liam mail <> wrote:
>> On 20 September 2011 12:04, Dirk Laurie <> wrote:
>>>  The default set in luaconf.h for both package.path and package.cpath
>>>  in Lua 5.2.0 beta puts the present working directory last, whereas in
>>>  Lua 5.1.4 it was put first.[...]
>>> It is difficult to understand why this change has been made.  It causes
>>> any application distributed with customized versions of packages that
>>> happen to installed system-wide to break unless the application explicitly
>>> sets the path.
> Arguments for the new behavior were raised in [1,2].
> Note that the path "./?.lua" is relative to the current directory, but
> you'd probably rather search relative to the Lua executable (i.e. "!"
> style LUA_PATH in Windows / LuaDist setprogdir [3]) or relative to the
> current script [4-8].  Perl's FindBin and "use lib" [9] do this well,
> and I've contemplated writing the analogue of both modules for Lua,
> and submitting it to distributions like LuaForWindows, because the
> need is so common.  IMO, "./?.lua" is a hack that introduces some
> modes of failure.
> [1]
> [2]
> [3]
> [4]
> [5]
> [6]
> [7]
> [8]
> [9]

The only argument there seems to be
"That is, above being a security risk, and not in the
control of the script, but the caller...what am I missing? I have to
parse package.path to remove those entries"

To be honest I do not understand this logic. If you are wanting to
create a sandbox then you have to modify Lua anyway and unless you do
so there is nothing I can see from stopping the caller from
reintroducing dot slash to that start of the search paths.