Re: [ANN] LuaFileSystem 1.7.0

[Sean Conner <sean@...>]

It was thus said that the Great Russell Haley once stated:
> On Sat, Sep 16, 2017 at 2:16 PM, Sean Conner <sean@conman.org> wrote:
> > It was thus said that the Great Russell Haley once stated:
> >
> >> Could someone please *name* a filesystem that they use Lua on that is
> >> *not* windows or posix compliant?
> >
> >   I can name several---VMS, AmigaOS, MS-DOS 1.0, CP/M.  But ones that are
> ooh, VMS, good one! Still in use and someone uses lua though?

  I would *love it* if Lua was used under VMS.  The directory stuff there is
wild compared to what we are used to today.  But even AmigaOS would be good
as it's just enough different from POSIX/Windows to make it interesting.

> >   Okay, for a simple job of listing files in a directory, we have:
> >
> >         Windows:
> >
> >                 directory needs to be the current working directory
> >                 pattern matches case-insensitive
> >                 people will use '\' out of habit
> >                 OH!  Also, Windows returns metainformation about each file
> >
> >         POSIX:
> >                 can do any directory
> >                 pattern matches case-sensative (maybe except for OS-X)
> >                 people will use '/' because that's the only path separator
> >                 OH!  POSIX only returns the name, no metainformation
> 
> We know at compile time if the system supports windows, posix or none
> of the above. Why not provide an extensible layer, provide a Windows
> and POSIX libraries that are compiled in via options, and let everyone
> else fend for themselves?
> 
> I guess it's really just a matter of perspective on what is part of an
> operating system. Lua interactivity with the shell is provided, I
> assume interaction to system call through C, but nothing else really?

  Lua uses C89 (with two exceptions) for *everything*.  It's the C runtime
that Lua uses that makes the system calls.  The two exceptions that I can
think of are:

	1) readline (POSIX if it's installed, not sure about Windows) for
	handing interactive input of the standalone executable

	2) the loading of C-based Lua modules using POSIX or Windows
	specific calls to load the shared objects into memory.

> The terminal is only supported through a third party. And yet lua
> *almost*[1] requires the user to interact with a filesystem to load
> scripts (well, it does "require()", but I mean the literal term). In
> interactive mode it *requires* a library to interact with the user. I
> think that's why people baulk at the fact these tools are not standard
> (myself included).

  Ehhhh ... it cheats.  Assuming a module written in Lua, when you do
require() on it, the code goes through package.path:

./?.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

splits it apart at each semicolon:

	./?.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

Then for each of the above, it substitutes the '?' with the module name and
the result is passed to fopen() (the C function):

	./MODNAME.lua
	/usr/local/share/lua/5.1/MODNAME.lua
	/usr/local/share/lua/5.1/MODNAME/init.lua
	/usr/local/lib/lua/5.1/MODNAME.lua
	/usr/local/lib/lua/5.1/MODNAME/init.lua

As far as Lua is concerned, these are "magic strings" passed to fopen().
It's similar for C-based modules, but that uses package.cpath and a system
specific call to load the shared object.

  But there's nothing preventing loading modules from something other than a
file.  I did work were I loaded Lua based modules directly from a ZIP file;
at work, I have an application that includes all required modules built in
(those in Lua are compressed and part of the executable) and I extended
require() to load said modules.

  -spc

> [1] dynamic scripts generated in memory and so forth, data passed
> through C etc. My details are still fuzzy around possibilities here.