Re: require() relative to calling file

[Sean Conner <sean@...>]

It was thus said that the Great Russell Haley once stated:
> On Fri, Feb 3, 2017 at 1:14 PM, Sean Conner <sean@conman.org> wrote:
> 
> >   But this is something *UNIX* does not provide "out of the box."
> 
> But if the arg[0] contains path denoting characters (/,\), why not
> parse out the path and add it to the search path for require? Then
> both scenarios are intrinsically covered with *very little* overhead.
> It's done once when the calling script is executed.

  The argument is over who is responsible for doing so?  The Lua stand alone
interpreter?  The Lua library that's embedded in a C application?  The
application written in Lua?  

  I would put it with the application written in Lua, but that's me.

> >   Unix has no concept of an "application path".
> 
> Are we talking about Unix or Lua? I would argue Unix and "Lua on Unix"
>  and even C assumes that the current path is the "application path",
> which is why all these system searches the current path in various
> system functions. In Lua, it searches the current path for require
> modules even if the script is in a different directory! Also, what
> would you think if "ls" only searched the current path when you
> specified a path in your search string?

  Lua searches the current path because the default Lua path (and cpath)
contain './?.lua' as one of the components.  And unless './' is part of
$PATH, a Unix shell *WON'T* execute a program in the current directory:

	[spc]lucy:/tmp>touch foo
	[spc]lucy:/tmp>chmod 755 foo
	[spc]lucy:/tmp>foo
	-bash: foo: command not found
	[spc]lucy:/tmp>./foo 
	[spc]lucy:/tmp>

I would have to add "./" to my path to execute a command in the current
directory:

	[spc]lucy:/tmp>export PATH=./:$PATH
	[spc]lucy:/tmp>foo
	[spc]lucy:/tmp>

  If executing a program in the current directory works, it's because "./"
was added to $PATH (and $LUA_PATH and $LUA_CPATH) at some point; it's far
from a default.

  Unix has a "current working directory" concept.  It does not have an
"application directory" concept.  Windows does (and the two can be different
when a program runs).

> >And neither does C for that
> > matter.  Remember, Lua uses the standard C library [2] and the C standard
> > library makes no mention of paths (or directories for that matter).
> 
> Sure, you are correct. But as you pointed out, Lua is portable to
> non-Unix systems that do not have path concepts, but it DOES use paths
> in systems that support it. 

  Not really.  All it does is apply some textual transformations to a
filename before ultimately calling fopen() (the C call).  If some
hypothetical system out there used '#' as a path seperator, then Lua would
still be able to load files in a relative manner.  It just that instead of
package path being:

  ./?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/local/lib/lua/5.1/?.lua;/usr/local/lib/lua/5.1/?/init.lua

it would be:

  .#?.lua;#usr#local#share#lua#5.1#?.lua;#usr#local#share#lua#5.1#?#init.lua;#usr#local#lib#lua#5.1#?.lua;#usr#local#lib#lua#5.1#?#init.lua

  To Lua, these are just opaque strings used to create potential filenames.

> So, as I said, why not parse arg[0] for
> appropriate path delimiters and use them when provided? "Because it's
> hard" does not seem like a very good reason. Moreover, as you pointed
> out parsing arg[0] for delimiters is not what would be consider a
> difficult task (albeit C has surprised me before! ha ha).

  Again, I think the argument is about where this happens.  

> I think it would be much better to say:
> 
> On all platforms that support file systems, Lua will:
> 1) Search the current directory

  Lua does this already.

> 2) Search the path of the executing script when it differs from the
> current path (i.e. the user has specified extra path information)

  Not all systems that have file systems support directories.  Granted,
they're not in popular use, but they do exist.  And given the relunctance of
the Lua team to support C99 (dispite being 18 years old) I don't see them
adding this any time soon.  I could be wrong though.

> 3) Package.path and package.cpath (which has environment variables
> appended if I understand correctly)
> 
> I could see it getting more complicated if a relative path was
> specified, but environment variables can have relative paths too.
> 
> This next comment is not about you, Sean, but a general comment about
> arguments made in Lua's defense: I think it's funny how on one side
> some people argue that Lua is not C and not bound by it's constraints
> and design guidelines, 

  Yes, and I'm one of those.

> but on the other side the argument is made that
> Lua uses standard C so is intrinsically tied to C idiosyncrasies? I
> would categorize this as an arbitrary use of ISO C limitations for
> covering a "not in my Unix" argument.

  And I argue that as well.  It's just that to ensure maximum portability,
you have to realize that Lua is built upon C89 only.  You want to interate
through entries in a directory?  Well, the code for that *IS* system
dependent (Unix, Windows, AmigaOS, and VMS all have a different API for
that).  But once you have such code, there's no reason to tie it to a
specific API---you can "Luaize" it (for lack of a better term).  So, for
example:

	for entry in dir("some/path/to/somewhere") do
		print(entry)
	end

could work regardless of the underlying C API.  

> >   So what *is* this trivial solution then?
> 
> Parse arg[0] for path delimiters and include that path in the search
> criteria for modules. Trivial...

  So add it to your Lua application.  That way, you don't have to wait for
the Lua team to add it.

  -spc