lua-users home
lua-l archive

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


A few things:

On 15-Jan-06, at 12:43 PM, Chris Marrin wrote:

The original lposix package had this, but it had a third 'overwrite' param. I don't think this is needed, since you can see if a variable exists with os.getenv() and then avoid calling osex.setenv() if so.

setenv with overwrite (should be) atomic, which you cannot achieve with getenv/setenv. However, I don't think anyone actually uses this feature as a locking mechanism, so I don't see any need to reproduce it.

Given that, it seems like a table interface to getenv/setenv is much more natural than a function call interface. Moreover, it's faster. It also makes it easy for a sandbox to provide a fake environment. So personally, I'd prefer to scrap both getenv and setenv, and just provide an os[ex].env table.

putenv has the odd characteristic that the string you provide is mutable; changing the string is supposed to change the environment variable. ("This is the only way to guarantee that changing the environment doesn't leak memory.") There doesn't seem to be any obvious way to implement this in Lua; it does not conform to Windows env variable semantics, and so I agree that it should simply be scrapped.

Almost all of your remaining functions have to do with the filesystem, not the operating system; the exceptions are sleep() and possibly errno(). I think sleep() is uncontroversial; the remaining filesystem-related calls should go into a filesystem library, not an os library (imho).

errno() is very difficult to use from a scripting language; it is not easy (or possibly even possible) for the scripting language to know that there have not been any intervening calls which may change errno. In addition, POSIX semantics require errno to be unchanged by calls which do not return an error value. (However, iirc it also used to require that floating point errors be reported in errno.) Managing errno is therefore replete with subtle bugs. Finally, there are environments in which different "OS-like objects" use different errno-like globals.

On the whole, I think that errors should be retained with OS-like objects, which is essentially the semantics of standard C i/o, for example, where each FILE has its own error indicator (which can be both read and cleared.) That would be possible to implement, and I think it would be easier to implement that in an OS-independent way. In addition, it would be easier to use. Say, for example, that both files and sockets had a lasterror() method (or a lasterror key). That would make it much easier to write loops which respected error conditions:

  for line in f:lines() do
    ...
  end
  if f:lasterror() then   -- or possibly "if not f.eof"
    ... report the error
  end

I personally think that open() should be a member function on a directory object, rather than a global. An implementation should provide both a root directory object (sort of the analogy to stdin) and (if possible) a cwd() function; regardless, there would be some object onto which open() errors could be attached. This would simplify programming of directory traversal functions as well.