Re: os.setenv()???

[D Burgess <dburgess@...>]

Amongst those of us who think this is worthwhile doing, there
appears to be some consensus. Certainly we have common aims.

May I suggest an incremental approach:

1) Lets decide on a library name e.g. osext or osex  are my
suggestions.

2) Implement a handful of functions that are currently in use by
one or more of us. putenv/setenv/stat would be a fair start.
I personally like Luiz's get/set/put env that is in the posix library.

3) Find someone to own (moderate) the library growth. If Luiz
and/or Diego would like to take on the role? this would be a
good thing.

Initial aims:

a) not fat
b) cross platform (e.g. mac/unix/win)
c) "carefully specifying and documenting a set of useful
interfaces which are commonly available on most platforms, as well as a
simple means of discovering whether the given interface exists" - thanks
Rici

DB




On 1/9/06, Rici Lake <lua@ricilake.net> wrote:
>
> On 8-Jan-06, at 6:27 PM, David Given wrote:
>
> > Also remember that any additional layers of abstraction mean extra
> > code,
>
> As I said before, changing the name of a function (from putenv to
> setenv, or from Write to write) costs nothing. :)
>
> >  and
> > Lua is primarily an *embedded* language. Most Lua programs aren't
> > intended to
> > be portable because the author knows exactly the platform that it's
> > going to
> > run on.
>
> I wonder if that's true. I've primarily used Lua for two things:
>
> 1) A configuration system for utilities
> 2) A glue language for scripting internet servers.
>
> In both cases, the embedding application is attempting to be
> cross-platform, often at an agonizing cost. The configuration /
> scripting interface, which is designed for non-programmers, attempts to
> abstract the differences away (fortunately, that's not usually
> difficult.) Such people would probably not like either:
>
> filesize =
> RootFilesystem:findfile("/home/dg/documents/sample.txt"):size()
>
> or
>
> filesize = posix.stat("/home/dg/documents/sample.txt").st_size
>
> but the first would at least work consistently on Unix, MacOSX and
> Windows, which saves me a lot of documentation effort and makes it
> easier for the clients to switch platforms without rewriting their
> scripts. (I'm skating over the backslash issue here, although
> fortunately slashes work on windows these days; the biggest problem is
> convincing people to not write backslashes or to double them. These are
> the sort of things that create helpdesk calls. I'd hate to think of the
> complications which using .st_size might cause :)
>
> I find that it's pretty easy to get people to write stuff like:
>
> for f in folder(env.HOME) do -- [Note 1]
>    if f.extension == "doc" and f.size > 4 * megabyte then
>      print(f.fullname .. " is way too big.")
>    end
> end
>
> In fact, I prefer that myself :)
>
> I don't see how that creates extra code. Supporting N platforms with
> different directory APIs creates extra code, but thin wrappers don't
> help that; on the other hand, using thin wrappers bulks up every
> script, whereas the support code is only written once.
>
> Let me be 100% clear. I am not proposing any of the following:
>
> -- bundling a large set of cross-platform libraries with the standard
> Lua distribution
>
> -- shooting people who write platform-specific interfaces
>
> All I'm suggesting is that if we put our heads together, we ought to be
> able to come up with a nice clean set of documented interfaces which
> *could* be used by people to implement OS support libraries in a
> standard, Lua-like way. The market would then decide, I suppose, but
> I'd be betting that the standard interfaces would have a lot of market
> support.
>
>
> [Note 1]
> To handle the difference between Windows and Unix environment
> variables, I use a pseudo-environment table which translates names. I
> wouldn't suggest doing that in a standard interface, but it's avoided a
> lot of problems.
>
>