lua-users home
lua-l archive

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

Am 07.09.2016 um 16:40 schrieb Dirk Laurie:
Every time I require lfs, I ask myself: why is this stuff not in the
os library?

I understand that not all systems support everything that lfs
has. And that Lua is very platform-independent.

But the goal of platform-independence does not stop Lua
from offering os.execute, which invites the user to write
platform-dependent code, and io.popen, which "is system
dependent and is not available on all platforms".

The absence of functions so basic that even CP/M and PC-DOS
had them is the one thing that stops Lua from breaking into
the Perl/Python cartel of scripted system programming.

If all of lfs is too much, here is my order of preference:

1. dir
2. chdir, mkdir, rmdir, currentdir
3. attributes, setmode, touch
4. lock, unlock, lock_dir
5. link, symlinkattributes

I know why i is not in the standard libs: it is not the same functionality on all platforms. And it can't be implemented for all platforms with same (or at least similar) functionality.

Some platforms do not have a "current directory", so chdir and currentdir are not defined there
Some do not even have directories. Good bye, mkdir and rmdir...
Locking may not be available
Same applies to links.
Attributes are different (archive bit vs. executable...)

I once had to implement a "FAT file system version" of lfs, without current directory, links, and with different file attributes at my job. Wasn't too difficult. And had to be done in any case, as I doubt that the OS I have to deal with is on the list of implementers' favourites...(No, it's not any x86 architecture),
so it was unlikely that I would have found it being done already.

As a Lua user I understand that additional libraries may behave different on different platforms, however
I would expect that the standard libs behave the same.