Re: ex API

[Chris Marrin <chris@...>]

Mark Edgar wrote:
> http://lua-users.org/wiki/ExtensionProprosal
>
> 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:

    http://www.die.net/doc/linux/man/man3/execvp.3.html

    "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()

and

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

and

    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                ,""$,
chris@marrin.com          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"'