lua-users home
lua-l archive

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


It was thus said that the Great Sebastien Lai once stated:
> Recently I've stumbled upon an annoying, if not strange behaviour regarding
> the behaviour of 'require()'.
> In short, it seems that require() only searches from the directory from the
> script that is being called, for example:
> 
> 
> /path/to/somedir/main.lua
> |--> /path/to/somedir/system/
> |----> /path/to/somedir/lib/foo.lua
> |----> /path/to/somedir/lib/stuff.so
> 
> Main.lua being:
>     package.path = package.path .. ";../system/lib/?.lua"
>     require("foo")
> 
> Foo.lua being:
>     require("stuff")
> 
> In this case, the VM will search for "/path/to/somedir/stuff.lua", or
> "/path/to/somedir/stuff.so", but not for
> "/path/to/somedir/system/lib/stuff.so" or
> "/path/to/somedir/system/lib/stuff.lua", as for example Python does.
> 
> That is, Lua does not search the relative path, which makes using organized
> module directories rather tiresome to use...
> It wouldn't be all that terrible if one wouldn't have to explicitly add the
> following to "main.lua":
> 
>      package.cpath = package.cpath .. ";../system/lib/?.so"
> 
> A wake mind will see the problem here: the line has to be modified to match
> the extension for shared libraries on each system.
> I simply do not believe that this is intended, and writing a crossplatform
> version of 'dirname' is trivial, so why is this functionality not part of
> Lua yet?

  From my understanding, Lua only provides functionality that's found in C89
and no more (and dirname() is not part of C89).  Yes, it *could* be added,
but it's not quite as straightforward as it seems, and given a sufficiently
oddball system, even the current module system may break.  

  For example:  VMS.  Oddball these days, but it wouldn't surprise me to
learn that a few are still around and in production (and it was a highly
popular system in the 80s).  The file specification for it is very odd by
Windows/Unix standards (which now includes the Mac, since it's Unix
underneath).  The full spec is:

nodename::diskname:[directory.subdirectory...]filename.extension;version

so, a Lua script might be:

	KREMVAX::$USR:[source.scripts.lua]frob.lua;45

(Translated:  version 45 of the frob.lua script in the directory
source.scripts.lua on the user disk found on the machine named KREMVAX)

  Parent directories are specified by '-', not by '..'.  And as it should be
obvious, path segments are separated by '.', not by the '/'.  And the entire
directory is found embedded in '[' and ']'.  On such a system, all I would
have to do in Lua is:

	package.cpath = package.cpath .. ";[-.system.lib]?.so"

(assuming shared libraries under VMS end with a .so extention; on that, I'm
not sure) Is it realistic to expect a sizable number of Lua users on VMS
systems?  Hard to say.  As it is right now, the current module system could
work on VMS, although you lose the ability to specify a version number.

  Also, why "../system/lib/?.so"?  Why not "../lib/?.so"?  or even
"../libexec/?.so"?  

  -spc