Re: [ANN] LuaFileSystem 1.7.0

[Russell Haley <russ.haley@...>]

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:
>
>> Sorry for the top post.  LuaRocks is awesome and Lfs suites my needs so it
>> makes little difference but it leaves me with questions.
>>
>> 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?

> still in use?  I don't know.  I want to say that iOS and Android file access
> is different, but I don't program those (I just hear the complaints at
> work).  But in general, you are right, POSIX and Windows file systems cover
> probably 99.44% of all computer use today.
>
>> Also, I have trouble thinking that filesystem access can't be generalized
>> enough to make it extensible. Please, educate me otherwise.
>
>   There are semantic differences between the two that would make this ...
> interesting.  Just iterating over files in a directory.  Windows (which is
> based off MS-DOS---I have no Windows development experience so I'm falling
> back on my MS-DOS arcana here so if the details have changed, forgive me)
> has FindFirst() and FindNext().  They work on the current working directory
> and it takes a pattern to look for---"*.c" or "foo.*" for example).
>
>   POSIX has opendir() and readdir().  It will work for any directory, but it
> takes no pattern---it just returns all the files in a directory in an
> unspecified order.  POSIX also has a function to return all files matching a
> pattern ("*.c" or "foo.*" for example) but I've found it has ... quirks
> (namely, if *no* files match, it returns the original pattern!).
>
>   The other major difference is the patterns themselves.  Yes, there are
> some patterns that cross ("*.c" or "foo.*") but the pattern for "all files"
> is different ("*" for POSIX, "*.*" for Windows).  Also, under Windows, the
> matching is case-insesitive ("foo.*" will match "FOO.ASM" and "foo.o") while
> they aren't for POSIX (but they *might* for Mac OS-X---that's a weird
> system).  So there's that to watch out for.
>
>   Then there's the path separator ("\" for Windows, "/" for POSIX, although
> Windows *does* support "/" for the separator as well).
>
>   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?
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).

On this mailing list we can see that there are thousands of opinions
of what should be done with Lua and what options should be included.
Perhaps the next great feature could be an upgrade to the build system
that would allow someone to build in the options they see fit? On the
flip side, I see potential though for much grief caused by compiled in
features.

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

>   And that metainformation?  Again, some differences between the two.
>
>   Your job, should you choose to accept it, is to figure out the semantics
> of a Lua directory iterator.
If I could do that, I promise you I wouldn't be on the mailing list
right now writing emails. ;)

>   -spc
>
>