Re: Proposal: Virtualization of Filesystem Operations for Lua 5.2.

[Sean Conner <sean@...>]

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.