[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Unpicking require
- From: Andrew Gierth <andrew@...>
- Date: Wed, 24 Nov 2021 19:25:19 +0000
>>>>> "Gavin" == Gavin Wraith <firstname.lastname@example.org> writes:
Gavin> But I am not sure which sense the dot has in these cases. Is it
Gavin> 'current directory' or 'filename-extension-introduction'?
My understanding of the code is this:
The intention is that the string passed to "require" should use the '.'
character as the hierarchical separator on all platforms, and therefore
it needs to be replaced by a possibly platform-specific separator when
it would otherwise appear in pathnames or symbol names.
The explicit uses of "." or '.' in loadlib.c are therefore as follows:
ll_searchpath() (implementation of package.searchpath) uses '.' as the
default separator to be replaced by LUA_DIRSEP
findfile() uses '.' as the (fixed) separator to be replaced by
loadfunc() replaces '.' by LUA_OFSEP (defined as '_') to form a symbol
name when looking for luaopen_X() in a loadable module
searcher_Croot() is the searcher for the "all in one" C module format,
where require "foo.bar.baz" is treated as a request for a symbol
luaopen_foo_bar_baz() in a C module found by searching in cpath for
"foo". It therefore uses '.' as the separator to split off that first
So all of these uses of '.' reflect the (conceptually) hierarchical
structure of the strings passed to require() and are therefore not
dependent in any way on the choice of OS.
The _only_ place where '.' reflects a "file extension" is in the actual
default values of LUA_PATH and LUA_CPATH, and if you change those to
remove the .lua and .so strings, then nothing in the package system
should use file extensions at all.
Gavin> At present 'require "foo"' works as it should for RISC OS, but
Gavin> 'require "foo.bar"' does not. I would like all dots in the
Gavin> argument string to 'require' to be passed through to the
Gavin> file-loading functions unchanged. I wondered whether the
Gavin> explicit mention of "." in the loadlib.c sources was the cause
Gavin> of my problem.
It should not be the cause of your problem.
It seems to me like it should work to define LUA_DIRSEP as "." and
modify the LUA_PATH and LUA_CPATH to conform to your OS's conventions.