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:16 AM, Scott Morgan <blumf@blueyonder.co.uk> wrote:
> > On 02/03/2017 07:34 AM, Russell Haley wrote:
> >> But the question was what is the argument against the approach
> >> described. ‎ It always has seemed to me that Lua goes to great length
> >> to search relative paths and entirely negates to look in the
> >> application path for no reason whatsoever. It was one of the most
> >> confusing things when I first started looking at Lua.
> >
> >
> > Lua does use the EXE path in Windows, but under *nix systems things
> > aren't so simple. There's no guarantee that the path to the executable
> > exists and no clear way to determine it even if it does[0] (some hacky,
> > platform dependant ways, but nothing clean).
> 
> How is that any different than the paths added via environment
> variables or package paths? In fact, the majority of search parameters
> will never exist (Have you seen some of the crazy search patterns
> used?), but they are searched JUST IN CASE someone did something
> fancy/stupid, but the path for the executing script in is not checked.

  That's because *WINDOWS* makes the EXE path available to the application. 
Unix *DOES NOT*.  Take the following C program:

	#include <stdio.h>
	#include <stdlib.h>
	
	int main(int argc,char *argv[])
	{
	  printf("%s\n",argv[0]);
	  return EXIT_SUCCESS;
	}

  I ran the program:

	GenericUnixPrompt> ./whatpath
	./whatpath

  I then copied the program to a location covered by $PATH.

	GenericUnixPrompt> whatpath
	whatpath

  So, where did I install 'whatpath'?  Here's $PATH:

/home/spc/.luarocks/bin:/home/spc/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/root/bin

  Okay, I do have options.  If arg[0] only contains a program name (no path
components like '/') then I *could* walk each element of $PATH, adding in
arg[0] and checking the existence of the program to find where it's located. 
So now we have:

	GenericUnixPrompt> whatpath
	arg[0]: whatpath
	path:   /home/spc/bin/whatpath

  Okay, even in C this wasn't a terrible amount of code (around 40 lines or
so to walk down $PATH) but you are still talking about string manipulation
in C (and it took me a few passes to get correct---I think).  I'm even
reasonably certain it will work on Windows, as is [1].

  But this is something *UNIX* does not provide "out of the box."

> > See luaconf.h (search WIN32) and loadlib.c (search for windows.h)
> >
> > Personally, I go with a shell script wrapper that sets the LUA_PATH etc.
> > environment vars before launching the app/Lua interpreter
> 
> Yes, there are many ways around it, but again, Lua seems to go to
> great lengths to use relative paths and search hither and yander but
> negates the application path arbitrarily. I say arbitrarily because
> there is no good reason to NOT search it (thus far). 

  Unix has no concept of an "application path".  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).

> However:
> 
> 1) It makes logical sense in terms of user expectation. Running
> 
>     [user@computer~]$ lua ~/mylib/script.lua
> 
> And NOT finding all the required modules causes a dissonance that the
> user must overcome. Why force this when a dead simple solution is
> present?

  It's not necessarily simple under Unix.

> 2) It makes your code more portable. By simply checking the
> application path after the current path (or potentially vis-versa)
> developers can package things together and users can now run
> applications from anywhere without the requirement of a script. Why
> force a user to write a wrapper?
> 
> 3) If the windows version of Lua does indeed search the application
> path, why use two different patterns when the solution is trivial?

  So what *is* this trivial solution then?

  -spc

[1]	Thankfully, Windows will accept '/' as a path separator.

[2]	With one or two exceptions, like io.popen() or a way to specify the
	"application path" under Windows, which will fail in Unix.