[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: require() relative to calling file
- From: Sean Conner <sean@...>
- Date: Fri, 3 Feb 2017 16:14:30 -0500
It was thus said that the Great Russell Haley once stated:
> On Fri, Feb 3, 2017 at 1:16 AM, Scott Morgan <email@example.com> 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 (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:
int main(int argc,char *argv)
I ran the program:
I then copied the program to a location covered by $PATH.
So, where did I install 'whatpath'? Here's $PATH:
Okay, I do have options. If arg only contains a program name (no path
components like '/') then I *could* walk each element of $PATH, adding in
arg and checking the existence of the program to find where it's located.
So now we have:
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 .
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  and the C standard
library makes no mention of paths (or directories for that matter).
> [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
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?
 Thankfully, Windows will accept '/' as a path separator.
 With one or two exceptions, like io.popen() or a way to specify the
"application path" under Windows, which will fail in Unix.