lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Wed, 7 Sep 2016 16:40:42 +0200
Dirk Laurie <> wrote:


I'm not interested in yet another naive more-batteries-included
filesystem interface. But it would be great if there was a virtual
filesystem interface in Lua's core. Edge cases I would like to have

- to allow for asynchronous I/O
- to allow for pluggable handlers that can mount into the
virtual namespace

One such pluggable handler would allow to require() or dofile() from a
ZIP archive or from memory, for example. These are traits that I
suspect would need to go to the core.

The concrete implementation of that interface that would be shipped
with Lua is not so important to me. By default it should be really just
a thin, naive wrapper on ANSI and POSIX. Directory functions could even
return an error if the functionality is by default not supported. But
you could require for example a "fs.default" handler to implement the
filesystems of most common operating systems.

> Every time I require lfs, I ask myself: why is this stuff not in the
> os library?
> I understand that not all systems support everything that lfs
> has. And that Lua is very platform-independent.
> But the goal of platform-independence does not stop Lua
> from offering os.execute, which invites the user to write
> platform-dependent code, and io.popen, which "is system
> dependent and is not available on all platforms".
> The absence of functions so basic that even CP/M and PC-DOS
> had them is the one thing that stops Lua from breaking into
> the Perl/Python cartel of scripted system programming.
> If all of lfs is too much, here is my order of preference:
> 1. dir
> 2. chdir, mkdir, rmdir, currentdir
> 3. attributes, setmode, touch
> 4. lock, unlock, lock_dir
> 5. link, symlinkattributes

Kind regards,

Timm S. Mueller <>
Schulze & Mueller GbR, Jungstr. 2, 10247 Berlin,
Gesellschafter: Franciska Schulze, Timm S. Mueller,
Tel. +49 30 85610000,