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
Lua.
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:
http://www.gigamonkeys.com/book/files-and-file-io.html
because it had [1] to handle filenames like:
System File Name
==================================================
TOPS-20<LISPIO>FORMAT.FASL.13
TOPS-10 FORMAT.FAS[1,4]
ITS LISPIO;FORMAT FASL
MULTICS>udd>LispIO>format.fasl
TENEX<LISPIO>FORMAT.FASL;13
VAX/VMS [LISPIO]FORMAT.FAS;13
UNIX /usr/lispio/format.fasl
==================================================
(from http://www.ida.liu.se/imported/cltl/clm/node203.html)
-spc (And that's not even the tip of the iceberg ... )
[1] Today, you have Unix and Windows. And they're *mostly* compatible
[2].
[2] 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:
C:/windows/windows32/bin
C:\windows\windows32\bin
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.
