Re: Problems with lposix on win32

[Rici Lake <lua@...>]

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.