 |
lua-l archive |
|
|
||
|
Am 07.09.2016 um 16:40 schrieb Dirk Laurie:
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.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
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. -- Oliver