Re: about lposix

[Sam Roberts <sroberts@...>]

On Tue, Oct 17, 2006 at 12:04:49PM -0700, Mark Edgar wrote:
> Sam Roberts wrote:
> >On Tue, Oct 17, 2006 at 05:01:15PM +0200, Natanael Copa wrote:
> >>What do you think about this as a start:
> >>
> >>env.getenv(name)
> >>env.setenv(name, value)
> >>env.environ()
> >
> >What about:
> >
> >  env[name]
> >  env[name] = value
> 
> This is easy enough to do in pure Lua; it doesn't need to be provided by 
> a binary module, IMHO:

When I require 'blah' it doesn't matter to me how much of the
functionality is implemented in lua, and how much in C, though
I do care what apis I get.

> require "ex"
> local environ = {}
> function environ:__index(k) return os.getenv(k) end
> function environ:__newindex(k,v) os.setenv(k,v) end
> environ = setmetatable({}, environ)

Both are trivially implementable in terms of each other:

  function os.getenv(k)
    return environ[k]
  end
  function os.setenv(k,v)
    environ[k] = v
  end

Which, or both, shall be part of the "almost standard" library?  I have
found apis that treat the environment as a table nicer to use than the
setenv/getenv versions.

Also, note that setenv()/getenv() doesn't allow you to iterate the
environment, at least one more function is required if the
procedural/non-table API approach is taken.

> >>I'd like to add "glob" but I don't know how it can be implemented in 
> >>windows.
> >
> >Worst case - code it by hand
> 
> Sure.  Again, this is something that pure Lua can do when provided a 
> primitive directory iterator:

"*/*.c"?

glob allows patterns matching files in more than one directory, the dir
iterator+pattern match you show doesn't, though with a bit of recursion
its possible, of course, even glob(3) is implemented with opendir(), its
just nice not to have to recode glob() yourself from basic building
blocks, in lua or in C.


> in this case your Lua program is targetting POSIX and since the POSIX 
> glob() semantics are something that do not exist on other systems, your 
> program is inherently non-portable to non-POSIX, non-UNIX-y systems.

Not sure what your point is.

glob(3) can be implemented on non-UNIX systems as long as they actually
have a file system. Its just some wildcard matching.

_findfirst() is already a very similar function on Win32, just differs a
bit by API, and I didn't find any docs for what wildcards it supports in
my few minutes of googling.

Sam