lua-users home
lua-l archive

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

Mark Edgar wrote:

Some discussion here last month prompted me to design an extended API for Lua which aims at adding some standard features found in modern desktop and server operating systems (Windows, UN*X, MacOS). This is not meant to be a catch-all API for things like graphics or networking, nor is it meant to be added to the standard Lua distribution. This API simply provides some base-level operating system function which are not covered under the C standard, but are so ubiquitous as to be available on all (non-embedded) systems.

I've written sample implementations for Windows and "POSIX". These rough yet working implementations are only meant as proof-of-concept, but with a bit of polish, they could serve as the standard implementations for these two platforms.

Commence criticism.  :)

Sorry I dropped the ball on this a few weeks ago. Thanks for coming up with a nice strawman.

I am very confused about spawn, as it relates to exec(). I thought execvp() (which you used for the Linux implementation) replaced the currently running process with the given file, as stated here:

    "The exec family of functions replaces the current
     process image with a new process image"

But you used CreateProcess() on the win32 implementation, which I thought creates a NEW process without affecting the currently running process. It looks like you want the child process functionality from your doc.

Also, there is already a spawn() function on Linux systems, which behaves similarly to fork(), so maybe this would not be the best name for this function?

Personally, I have little use for exec(). I find pipe() and system() to do what I need in these areas. They are horrible, but I can get them to do what I need! I also have never had any need for an explicit file lock/unlock semantic. Seems like this is the domain of databases and transaction processing, so they would fit better in a package like that. But maybe many others see the utility of this.

I have become partial to Rici's proposal of an environment table with metamethods to interface it to the system environment. So you would say:

    print("user=", os.environ["USER"])     -- for getenv()


    os.environ["MY_FAV_COLOR"] = "yellow"  -- for setenv()


    os.environ["MY_FAV_COLOR"] = nil       -- for unsetenv()

FYI, the reason I dropped this is because Fusion needs additional functionality in our os and io support. Since Emma is web enabled, it would be a fine virus carrier if we allowed unchecked support for these two libraries (os.remove("/*") would not make many people happy :-)

So I am implementing a simple Access Control List system around the affected functions. When you load the "fusion" library it will replace os and io with versions that are ACL enabled. These versions will also have the extra functionality we have discussed here.

I will, of course, make all this available to anyone who needs it. But it will be included in the Fusion package, which is around 200K. I will try to follow any concensus agreed upon here for compatibility.

chris marrin                ,""$,          b`    $                             ,,.
                        mP     b'                            , 1$'
        ,.`           ,b`    ,`                              :$$'
     ,|`             mP    ,`                                       ,mm
   ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
  m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
 b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
 ```"```'"    `"`         `""`        ""`                          ,P`
"As a general rule,don't solve puzzles that open portals to Hell"'