lua-users home
lua-l archive

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

2016-09-08 1:25 GMT+02:00 Jerome Vuarand <>:
> 2016-09-07 16:23 GMT+01:00 Paul Moore <>:
>> Looking at the OP's first suggestion, does lfs.dir correctly handle a
>> directory containing a filename that's not encodable in the current
>> codepage on Windows? Sure it's (to an extent) a specialist case, but
>> it matters a lot to some applications.
> No, but the same problem applies to That's why I patch both
> Lua [1] and LFS [2] in my Windows builds [3].
> [1]
> [2]
> [3]
> Shameless plugs aside, I don't think Lua needs more stuff in the base
> libs. Lua is maintained by a few guys on their spare time. Seeing how
> releases are already quite infrequent, I don't think burdening them
> with more stuff to maintain instead of improving and evolving the core
> would benefit anyone.

I don't think lfs functions are left out of the standard libraries because
the Lua maintainers would find that an extra bother. I think it is because
the support libraries are not in core C, only in C compilers that support for
example Posix extensions.

I am not arguing for the stuff in luaposix, only for basic directory
awareness. Paths are essential to the package library anyway, so why
not in the os library where users can access them for another purpose
than finding modules?

> The standard libs are already quite sufficient for a very common set
> of use cases (manipulation of text files), and serve as an example of
> good practices for people that want to expand that.

They are very good for binary files too, now that string.pack/unpack
is available. Which makes it harder to understand why Lua can't DIR,
CHDIR, MKDIR, RMDIR. Every device that can read a USB stick
or SD card needs that functionality.