[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Proposal: Virtualization of Filesystem Operations for Lua 5.2.
- From: Sean Conner <sean@...>
- Date: Thu, 3 Nov 2011 12:59:51 -0400
It was thus said that the Great Patrick Rapin once stated:
> > You need to modify Lua sources to do that? Just add an entry to
> > package.loaders to scan a ZIP file for modules.
> You are right. The fact is that I was not aware of the package.loaders
> feature at the time I needed the special loading.
> Anyway, let's take another example.
> I currently would like to pass UTF-8 encoded path names on Windows.
> That concerns at least loadfile, dofile, require, os.execute,
> os.rename, os.remove, os.tmpname, io.open, io.input, io.output,
> io.lines and io.popen.
> What would be the best solution on current Lua ? Is it to rewrite all
> those functions?
Lua is based upon what ANSI C (1989) provides. And C89 does not provide
anything but a way to open a file with a given name. What that name is, how
it is formatted, is outside the scope of C89, and thus, outside the scope of
With that said, what does fopen() under Windows do when given a UTF-8
encoded filename? The UTF-8 encoding was designed to work well (given
sufficient values of "well") with ASCII (well, such that str*() functions
won't break any more with a UTF-8 encoding than with an ASCII encoding), and
usually fopen() ends up calling the underlying operating system functions to
"open a file" and simply passes along a blob of data terminated with a zero
byte as a "name".
> Probably could it be much easier if there is a well designed common
> virtualization layer.
This isn 't a new problem; it's been around for years. For example,
here's the Common Lisp approach:
because it had  to handle filenames like:
System File Name
ITS LISPIO;FORMAT FASL
-spc (And that's not even the tip of the iceberg ... )
 Today, you have Unix and Windows. And they're *mostly* compatible
 No one seems to realize that Windows can accept '/' as part of a
path. In fact, the following two file names point to the same file:
It was only CMD.COM that enforced the use of '\' as a path
separator, because MS-DOS inherited behavior from CP-M (which in
turn inherited the behavior from RT-11) of using '/' to designate
command switches (which under Unix is the '-' character). The
kernel of Windows (and MS-DOS, going back to 2.0) never cared which
was used; you could use either one.