luaposix/luaposix

Lua bindings for POSIX APIs

luaposix

By the luaposix project

This is a POSIX binding for LuaJIT, Lua 5.1, 5.2, 5.3 and 5.4; like most libraries it simply binds to C APIs on the underlying system, so it won't work on non-POSIX systems. However, it does try to detect the level of POSIX conformance of the underlying system and bind only available APIs.

For a while, luaposix contained support for curses functionality too, but now that has its own lcurses repository again, where it is being maintained separately.

luaposix is released under the MIT license (the same license as Lua itsef). There is no warranty.

Installation

The simplest and best way to install luaposix is with LuaRocks. To install the latest release (recommended):

    luarocks install luaposix

To install current git master (for testing, before submitting a bug report for example):

    luarocks install http://raw.github.com/luaposix/luaposix/master/luaposix-git-1.rockspec

The best way to install without LuaRocks, is to call the bundled build-aux/luke command, as shown in the build section of the included rockspec file, from a freshly cloned working copy.

Note that you'll be responsible for providing dependencies if you choose not to let LuaRocks handle them for you, though you can find a list of minimal dependencies in the rockspec file.

If you are repackaging or redistributing luaposix, it is better to start from a release tarball, because the master development branch is branch is unstable, and sometimes breaks subtly, or does not build at all, or provides experimental new APIs that end up being removed prior to the next official release.

Note that there are full logs of complete builds for every commit in Github Actions, which you can compare with your progress if you get stuck.

Use

The library is split into submodules according to the POSIX header file API declarations, which you can require individually:

    local unistd = require 'posix.unistd'

The authoritative online POSIX reference is published at SUSv3.

Documentation

The latest release of this library is documented in LDoc. Pre-built HTML files are included in the release, and contain links to the appropriate SUSv3 manual pages.

Example code

See the example program tree.lua, along with the many small examples in the generated documentation and BDD specs/*_spec.yaml.

For a complete application, see the GNU Zile.

Bugs reports and code contributions

These libraries are maintained by their users.

Please make bug reports and suggestions as GitHub issues. Pull requests are especially appreciated.

But first, please check that your issue has not already been reported by someone else, and that it is not already fixed on master in preparation for the next release (See Installation section above for how to temporarily install master with LuaRocks).

There is no strict coding style, but please bear in mind the following points when proposing changes:

0. Follow existing code. There are a lot of useful patterns and avoided traps there.

1. 8-character indentation using TABs in C sources; 3-character indentation using SPACEs in Lua sources.

2. Simple strings are easiest to type using single-quote delimiters saving double-quotes for where a string contains apostrophes.

3. Save horizontal space by only using SPACEs where the parser requires them.

4. Use vertical space to separate out compound statements to help the coverage reports discover untested lines.

5. Prefer explicit string function calls over object methods, to mitigate issues with monkey-patching in caller environment.

6. No non-POSIX APIs; no platform-specific code. When wrapping APIs introduced in POSIX 2001 or later, add an appropriate #if. If your platform isn't quite POSIX, you may find a gnulib module to bridge the gap. If absolutely necessary, use luke feature tests.

7. Thin wrappers: although some existing code contradicts this, wrap POSIX APIs in the simplest way possible. If necessary, more convenient wrappers can be added in Lua (posix.lua).

luaposix's Issues

Luaposix issue with gcc 4.7

Building luaposix v5.1.19 with gcc 4.7 let a lot of posix function missing

cat list_posix.lua

require "posix"

for i, v in pairs(posix) do
print(i, v)
end

lua list_posix.lua|grep func

cutime function: 0xcd3570
utime function: 0xccbd80
elapsed function: 0xcd35d0
system function: 0xcc9ff0
euidaccess function: 0xcd5180
creat function: 0xcc9f80

lua list_posix.lua|grep func|wc -l

6

Building the 5.1.19 with gcc 4.6.3 let around 82 functions available.

lua list_posix.lua|grep func|wc -l

82

Building old version 5.1.15 with gcc 4.7 let more functions available. But less than 5.1.19 with gcc4.6 (maybe those functions was introduced by new version)

lua list_posix.lua|grep func|wc -l

78

Cheers,

Remove dependency on lunit

The tests-fcntl.lua file should be rewritten to avoid needing lunit.

Unable to build 5.1.21 on Mac OS X 10.7

I am able to build 5.1.21 under linux. But I am unable to build it under Mac OS X 10.7. Because I am running automake 1.12.3, I had to add to configure.ac:

-Wno-extra-portability

added to AM_INIT_AUTOMAKE line. Without it the ./bootstrap doesn't build anything.

Under Linux it downloads gnulib via git and builds it. Under Mac, it doesn't clone gnulib. I am wondering it anyone has build this version under Mac. The last version I was able to build was 5.1.15

This is what it currently does after a successful ./configure:

% make V=1
make all-recursive
Making all in lib
make all-recursive
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -no-undefined -o libgnu.la
libtool: link: ar cru .libs/libgnu.a
ar: no archive members specified
usage: ar -d [-TLsv] archive file ...
ar -m [-TLsv] archive file ...
ar -m [-abiTLsv] position archive file ...
ar -p [-TLsv] archive [file ...]
ar -q [-cTLsv] archive file ...
ar -r [-cuTLsv] archive file ...
ar -r [-abciuTLsv] position archive file ...
ar -t [-TLsv] archive [file ...]
ar -x [-ouTLsv] archive [file ...]
make[4]: *** [libgnu.la] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Does anyone have any hints?

os x and ubuntu build and install from source not working

docs directory is depended on, but not made, and it doesn't install into package.cpath, or package.path.

% ./bootstrap&& ./configure && make
...
make[1]: Entering directory /Users/sam/p/sam-github/luaposix' CC posix_c_la-lposix.lo CCLD posix_c.la CC lcurses.lo CCLD curses_c.la /usr/bin/perl make_lcurses_doc.pl touch docs/index.html docs/ldoc.css touch: docs/index.html: No such file or directory touch: docs/ldoc.css: No such file or directory make[1]: *** [curses.html] Error 1 % mkdir docs % make ... touch docs/index.html docs/ldoc.css make[1]: Leaving directory/Users/sam/p/sam-github/luaposix'

.so installs into /usr/local/lib/, and .lua installs into /usr/local/share, but package paths are:

% lua -e 'print(package.cpath)print(package.path)'
./?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so
./?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/local/lib/lua/5.1/?.lua;/usr/local/lib/lua/5.1/?/init.lua

Empty posix.fcntl table

After a recent merge of setfl/getfl functions luaposix got empty fcntl table which does not do anything beside confusing users.

Please kick it out or move setfl/getfl functions to it (so it would make sense).

getopt()

Hi,

I just added getopt() to my fork at 1f5a5ffbc4d9af9f4f9e09a889263d53e3fa1243.

The semantics are a bit different from getopt_long() though (as I find it more logical this way), although I understand this could lead to confusion.

The iterator passes the following arguments:

• the option character as a string (instead of a number)
• the optarg, or true if this option has no value
• optind

Usage example:

local opt = {}
local lastopt = 1
for c, val, optind in posix.getopt(arg, "0lk:p") do
   opt[c] = val
   lastopt = optind
end

fdopen

It would be nice to have a wrapper for fdopen in luaposix. I wrote one myself a while ago [1] - it uses lextlib (a small library of mine) to conveniently parse its arguments, but those calls can easily be replaced with standard Lua functions. To implement it, I also had to copy some internal Lua functions out of lua-5.2.1 (the static ones at the top of the file).

[1] https://github.com/devurandom/lua-xio/blob/master/xio.c

Networking and existing 'socket' libraries compatibility

I recently left my private heap of C OS-support functions of the last decade behind in favor of luaposix, because most of the functionality I need in daily life is in here. The one big exception to this is networking; for this I still have my own layer of (very thin) functions on top of the socket API.

I never got to love luasocket because of the extra abstraction layer on top of the socket API. Luasocket handles are not file descriptors, there's an extra layer of buffering going on in recv() and select() and the like, and it generally does not play well mixing with C code.

I feel that mixing luasocket and luaposix can not really be done like it should, mostly because of their incompatible view on file descriptors and polling.

So, is this a problem that others share with me? And if so, what would be a feasible solution?

• Would it be possible to make luasocket and luaposix compatible in any way? This would probably mean allowing luasocket to 'open up' to the underlying implementation a bit?
• Would adding a thin socket layer to luaposix a sane thing to do? I guess minimal set of required functions would be: socket, bind, accept, connect, listen, send(to), recv(from), [gs]etsockopt, and probably some stuff for name resolving.

As a test for the latter option I have added some socket code in my zevv/luaposix fork at 9102db44182fb56223ea3417e54c2cfb3636ecf0.

New names?

I don't get it. With luaposix 5.1.15 the install looks like this

´´´
mambo-taa:5.1 axel$ ls -l /usr/local/lib/lua/5.1/
total 280
-rwxr-xr-x 1 root wheel 930 31 Jan 14:54 curses_c.la
-rwxr-xr-x 1 root wheel 72392 31 Jan 14:54 curses_c.so
-rwxr-xr-x 1 root wheel 915 31 Jan 14:54 posix_c.la
-rwxr-xr-x 1 root wheel 60600 31 Jan 14:54 posix_c.so
´´´

Why the _c ? of course require('posix') fails.

Preadlink should lstat instead of stat

Preadlink uses stat to determine the size to be allocated for storing the link target. This results in 2 bugs demonstrated by the 2 lua invocations below:

btb-authlete:~/ff/lua$ ls -l self source target
lrwxrwxrwx 1 dieter dieter 4 Oct 25 09:48 self -> self
lrwxrwxrwx 1 dieter dieter 6 Oct 25 09:44 source -> target
-rw-r--r-- 1 dieter dieter 5 Oct 25 09:44 target
btb-authlete:~/ff/lua$ lua -lposix -e 'print(posix.readlink("self"))'
nil     self: Too many levels of symbolic links 40
btb-authlete:~/ff/lua$ lua -lposix -e 'print(posix.readlink("source"))'
targe

After changing it to lstat:

btb-authlete:~/ff/lua$ lua -lposix -e 'print(posix.readlink("self"))'
self
btb-authlete:~/ff/lua$ lua -lposix -e 'print(posix.readlink("source"))'
target

readlink error: Invalid argument

> require('posix')
> =posix.readlink
function: 0x1e9c500
> =posix.readlink('/tmp')
nil /tmp: Invalid argument  22

Add dual-licensed support for building against gnulib/libposix

Luaposix currently relies on the POSIX support of the build host. gnulib provides much wider support for POSIX APIs, especially on older OSes which lack up-to-date support, and on Mingw where it is often lacking altogether; but also fixes many bugs on widely-used systems (in particular Mac OS X, but there are even some useful fixes for glibc):

http://www.gnu.org/software/gnulib/

The main problem is that gnulib is mostly GPLed (some of it is LGPLed, and a small part public domain); otherwise we could simply use it by default.

Hence this issue: I propose that:

a) luaposix be dual-licensed MIT/GPL (it might be possible to offer LGPL as well, as a useful subset of gnulib is available under LGPL, and gnulib's build tool allows LGPL'ed versions of modules to be selected; but it would be more work)

b) when a GPL build is made, gnulib is used. (This is pretty easy, just a question of adding gnulib to the build system along with a list of modules. The list could be updated whenever luaposix is extended, but that doesn't strictly have to be done, you simply don't benefit from extra portability/fixes if you don't update the list for newly added APIs.)

Finally, if a gnulib expert takes an interest in this issue, there's a potentially less invasive way to implement it: use libposix. (Explanation: gnulib is a source library; libposix is an builds the POSIX APIs into a standard binary library. However, libposix is still, I believe, experimental.)

Implementing this issue would enable luaposix users to get much greater portability and more robust functionality on a wider range of platforms if they can use the GPL, while retaining the flexibility to stick with the MIT license.

inadvertent use of stdlib in luaposix tests?

$ make  check-local
ls ./tests-posix.lua ./tests-curses.lua | LUA_PATH="/Users/gary/Devo/luaposix--github--0/?.lua;;" LUA_CPATH="/Users/gary/Devo/luaposix--github--0/.libs/?.so;;" xargs -L 1 /usr/local/bin/lua
posix library for Lua 5.1 / 5.1.28

[[...]]
------------------------------------------------------ pipeline
lua: /Users/gary/Devo/luaposix--github--0/posix.lua:73: attempt to index global 'list' (a nil value)
stack traceback:
        /Users/gary/Devo/luaposix--github--0/posix.lua:73: in function 'pipeline'
        /Users/gary/Devo/luaposix--github--0/posix.lua:130: in function 'pipeline_iterator'
        /Users/gary/Devo/luaposix--github--0/posix.lua:151: in function 'pipeline_slurp'
        ./tests-posix.lua:312: in main chunk
        [C]: ?
lua: ./tests-posix.lua:313: assertion failed!
stack traceback:
        [C]: in function 'assert'
        ./tests-posix.lua:313: in main chunk
        [C]: ?
make[1]: *** [check-local] Error 1
make: *** [check-am] Error 2

Do non-standard functions need a new module?

Most of the functions in posix.lua are not POSIX functions. Should they be put into a new module? It could be called "sys", by analogy with /usr/include/sys, or "posix_sys", or "posix_ext" (by analogy with lua-stdlib).

luaposix doesn't wok with Lua 5.1

This is what happens when saying "require posix" under Lua 5.1:

require "posix"
error loading module 'posix_c' from file '/usr/lib/lua/5.1/posix_c.so':
/usr/lib/lua/5.1/posix_c.so: undefined symbol: lua_tointegerx
stack traceback:
[C]: ?
[C]: in function 'require'
/usr/share/lua/5.1/posix.lua:2: in main chunk
[C]: in function 'require'
stdin:1: in main chunk

No such problem with Lua 5.2. As the README says "luaposix is a POSIX binding, including curses, for Lua 5.1 and 5.2", I think either the bug or the README should be fixed.

Bernd

Please add support for F_*LK options of fcntl()

It is, obviously, not possible to pass a pointer to structure from plain Lua, so a special code to support that is needed.

Recent commit using Lua 5.2 only functions breaking 5.1 compatibility

Installing the latest luaposix with luarocks yields:

$ lua
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> require('posix')
error loading module 'posix_c' from file '/home/nick/.luarocks/lib/lua/5.1/posix_c.so':
        /home/nick/.luarocks/lib/lua/5.1/posix_c.so: undefined symbol: lua_tointegerx
stack traceback:
        [C]: ?
        [C]: in function 'require'
        /home/nick/.luarocks/share/lua/5.1/posix.lua:2: in main chunk
        [C]: in function 'require'
        stdin:1: in main chunk
        [C]: ?

It was correctly built against Lua 5.1, as far as I can tell. The cause seems to be a recent change (67e01c8) which added calls to lua_tointegerx and lua_len, both 5.2 only.

Run tests on Lua 5.1 and 5.2

To prevent issues such as #71, "make check" should build and test against Lua 5.1 and 5.2.

Build broken

Build broken by commit 9f68d30

./configure: line 13394: syntax error near unexpected token `$_ax_test_ver,'
./configure: line 13394: `  AX_COMPARE_VERSION($_ax_test_ver, ge, 5.1)'

Unable to crosscompile luaposix

I had some trouble while integrating luaposix to my openembedded layer. During configure there are several checks which do break on crosscompilation. The check for the lua interpreter had been worked arround by building a native lua in oe. The comparision of the lua interpreter version and the header version required a patch to be solved:
https://github.com/project-magpie/meta-magpie/blob/master/recipes-devtools/lua/luaposix/fix_crosscompile.patch

I am not sure if this Patch is correct, because I am not the m4 guru at all ;)

fcntl testsuite is not called during make check

tests-fcntl.lua uses lunit which needs to be either called as lunit <testsuite> or the code running lunit.main need to be added to the end of testcase.

pushtm: monthday -> day

Hi!

https://github.com/rrthomas/luaposix/blob/master/lposix.c#L1835 -- .monthday is incompatible to Lua os.date(). Please, consider renaming to .day.

TIA,
--Vladimir

missing tag v5.1.19

Tag v5.1.19 is missing in git.

read() leaks memory in case of error

Pread() returns without freeing the buffer if the read() system calls return < 0

Proposed fix in 3b360574cbcc16a56778c89b36a167cde6b73b6b

There is no INSTALL file

In the Readme there is a reference to INSTALL but I could not find a file called INSTALL

[...]
luaposix uses the GNU build system. For detailed instructions, see
INSTALL. For a quick start:
[...]

configure doesn't detect the package.path, or package.cpath

Quoting from: #66

As for the second, ./configure cannot tell in which possible directory you'd like your packages installed; you have to specify, using the standard --libdir and --datadir arguments.

I verified the workaround works.

configure can tell, it already found the lua executable, it can just run lua -e 'print(package.path)', and sed out the first path that starts with /.

I wouldn't describe the use of libdir and datadir for this purpose as standard, are lua c modules really "object code libraries"?

The default that ./configure uses will never work (or is there someone that puts compiled modules in /usr/local/lib/?), and the work-around options are buried into the standard mountain of auto-cruft along with other options which I suspect are wholly ignored (--sbindir? --oldincludedir?).

`posix.times()` returns a keyed table, `posix.times {keys}` returns a list

Passing a list of keys to posix.times should produce a keyed table too, for consistency with the result of posix.times ().

A few Specl examples fail inexplicably on Travis

Oddly, all of these pass on my (Mac OS Mountain Lion w/Lua 5.1.5 from homebrew) and Reuben's dev machines :( But Travis, on Ubuntu Precise is unhappy with them for some reason:

Summary of failed expectations:
- lposix system configuration pathconf fetches the maximum formatted line input length for a tty:
  FAILED expectation 2: expecting exactly -1, but got 255
- lposix system configuration pathconf fetches the maximum raw line input length for a tty:
  FAILED expectation 2: expecting exactly -1, but got 255
- lposix system configuration pathconf fetches whether special character processing can be disabled:
  FAILED expectation 2: expecting exactly -1, but got 0

Plus an additional failure with only Lua 5.1:

- lposix file handling statvfs fetches statistics for a mounted file system:
  FAILED expectation 20: expecting exactly true, but got false

Feature: errno codes

It would be really useful to have errno codes as defined by POSIX.

Documentation for doc_gettime got lost

Finger-trouble with the luadoc file - we have doc_getres repeated twice.

luaposix 5.1.15-1 fails to install with LuaRocks on OS X

OS X 10.7.2
LuaRocks 2.0.7.1

The error:

/usr/bin/ranlib: file: .libs/libgnu.a(dummy.o) has no symbols
ranlib: file: .libs/libgnu.a(dummy.o) has no symbols
ranlib: warning for library: .libs/libgnu.a the table of contents is empty (no object file members in the library define global symbols)
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
  CC     posix_c_la-lposix.lo
lposix.c: In function ‘luaopen_posix_c’:
lposix.c:2078: error: ‘SIGPOLL’ undeclared (first use in this function)
lposix.c:2078: error: (Each undeclared identifier is reported only once
lposix.c:2078: error: for each function it appears in.)
make[1]: *** [posix_c_la-lposix.lo] Error 1
make: *** [install-recursive] Error 1

Error: Build error: Failed installing.

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Full output:

$ sudo luarocks install luaposix
Installing http://luarocks.org/repositories/rocks/luaposix-5.1.15-1.src.rock...
Using http://luarocks.org/repositories/rocks/luaposix-5.1.15-1.src.rock... switching to 'build' mode
Archive:  /private/tmp/luarocks_luarocks-rock-luaposix-5.1.15-1-6163/luaposix-5.1.15-1.src.rock
  inflating: luaposix-5.1.15-1.rockspec  
  inflating: luaposix-5.1.15.tar.gz  
LUA=lua CPPFLAGS=-I/opt/local/include ./configure --prefix=/usr/local/lib/luarocks/rocks/luaposix/5.1.15-1 --libdir=/usr/local/lib/luarocks/rocks/luaposix/5.1.15-1/lib --datadir=/usr/local/lib/luarocks/rocks/luaposix/5.1.15-1/lua
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for Minix Amsterdam compiler... no
checking for ar... ar
checking for ranlib... ranlib
checking build system type... x86_64-apple-darwin11.2.0
checking host system type... x86_64-apple-darwin11.2.0
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
checking the name lister (/usr/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for ar... (cached) ar
checking for strip... strip
checking for ranlib... (cached) ranlib
checking command to parse /usr/bin/nm output from gcc object... ok
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin11.2.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating ./config.lt
config.lt: creating libtool
checking for sigaction... yes
checking for sigaltstack... yes
checking for siginterrupt... yes
checking for C/C++ restrict keyword... __restrict
checking for uid_t in sys/types.h... yes
checking for inline... inline
checking for sigset_t... yes
checking whether the preprocessor supports include_next... yes
checking whether system header files limit the line length... no
checking for pid_t... yes
checking for unsigned long long int... yes
checking for long long int... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for stdint.h... (cached) yes
checking whether stdint.h conforms to C99... no
checking sys/inttypes.h usability... no
checking sys/inttypes.h presence... no
checking for sys/inttypes.h... no
checking sys/bitypes.h usability... no
checking sys/bitypes.h presence... no
checking for sys/bitypes.h... no
checking for bit size of ptrdiff_t... 64
checking for bit size of size_t... 64
checking for bit size of sig_atomic_t... 32
checking for bit size of wchar_t... 32
checking for bit size of wint_t... 32
checking whether sig_atomic_t is signed... yes
checking whether wchar_t is signed... yes
checking whether wint_t is signed... yes
checking for ptrdiff_t integer literal suffix... l
checking for size_t integer literal suffix... ul
checking for sig_atomic_t integer literal suffix... 
checking for wchar_t integer literal suffix... 
checking for wint_t integer literal suffix... 
checking for struct sigaction.sa_sigaction... yes
checking for volatile sig_atomic_t... yes
checking for sighandler_t... no
checking whether pthread_sigmask is declared without a macro... yes
checking whether sigaction is declared without a macro... yes
checking whether sigaddset is declared without a macro... yes
checking whether sigdelset is declared without a macro... yes
checking whether sigemptyset is declared without a macro... yes
checking whether sigfillset is declared without a macro... yes
checking whether sigismember is declared without a macro... yes
checking whether sigpending is declared without a macro... yes
checking whether sigprocmask is declared without a macro... yes
checking for sigprocmask... yes
checking for ANSI C header files... (cached) yes
checking for strlcpy... yes
checking for crypt... yes
checking for working ncursesw... no
checking for working ncurses... yes
checking Lua version is in range 501 <= v < 502... yes
checking lua.h usability... yes
checking lua.h presence... yes
checking for lua.h... yes
checking lualib.h usability... yes
checking lualib.h presence... yes
checking for lualib.h... yes
checking lua.h version is in range 501 <= v < 502... (found Lua 5.1, 501)... yes
checking whether perl executable path has been provided... no
checking for perl... /opt/local/bin/perl
checking whether md5sum executable path has been provided... no
checking for md5sum... false
configure: creating ./config.status
config.status: creating Makefile
config.status: creating lib/Makefile
config.status: creating luaposix.rockspec
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
make install
Making install in lib
  GEN    c++defs.h
  GEN    arg-nonnull.h
  GEN    warn-on-use.h
  GEN    signal.h
  GEN    stdint.h
make  install-recursive
  CC     dummy.lo
  CCLD   libgnu.la
/usr/bin/ranlib: file: .libs/libgnu.a(dummy.o) has no symbols
ranlib: file: .libs/libgnu.a(dummy.o) has no symbols
ranlib: warning for library: .libs/libgnu.a the table of contents is empty (no object file members in the library define global symbols)
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
  CC     posix_c_la-lposix.lo
lposix.c: In function ‘luaopen_posix_c’:
lposix.c:2078: error: ‘SIGPOLL’ undeclared (first use in this function)
lposix.c:2078: error: (Each undeclared identifier is reported only once
lposix.c:2078: error: for each function it appears in.)
make[1]: *** [posix_c_la-lposix.lo] Error 1
make: *** [install-recursive] Error 1

Error: Build error: Failed installing.

posix.chmod textual option does not behave like chmod(1)

While debugging LuaRocks issue #55, I found out that the second argument for posix.chmod() does not behave like the "chmod" command-line tool:

$ touch file
$ chmod 0777 file
$ ls -l file
-rwxrwxrwx 1 hisham users 0 Feb 10 17:32 file
$ chmod u=rwx,g=rx,o=rx file
$ ls -l file
-rwxr-xr-x 1 hisham users 0 Feb 10 17:32 file
$ chmod 0777 file
$ lua -e "require'posix';posix.chmod('file','u=rwx,g=rx,o=rx')"
$ ls -l file
-------r-x 1 hisham users 0 Feb 10 17:32 file
$ chmod 0777 file
$ chmod u=rwx,g+rx,o+rx file
$ ls -l file
-rwxrwxrwx 1 hisham users 0 Feb 10 17:32 file
$ chmod 0777 file
$ lua -e "require'posix';posix.chmod('file','u=rwx,g+rx,o+rx')"
$ ls -l file
-rwxr-xr-x 1 hisham users 0 Feb 10 17:32 file

Given that they share the same syntax, I assumed the semantics were supposed to be the same. But as you can see, in posix.chmod(), each "=" sign is resetting the entire value, while in chmod(1), the "u", "g" and "o" categories are handled separately.

I tried using this syntax in LuaRocks because I enable LuaPosix conditionally according to availability, and run os.execute("chmod ...") as a fallback. posix.chmod(file, "rwxr-xr-x") works as expected, but chmod(1) does not support that.

By any chance, do you know any syntax that works the same on both chmod(1) and LuaPosix 5.1.15? (That would spare me from leaking the abstraction in my code.)

setrlimit for memory doesn't seem to work.

No matter what I do, processes never get killed for memory. cpu and nofile work fine, though:

require "posix"
local limit = 100 * 1024^2
posix.setrlimit("data", limit, limit)
posix.setrlimit("stack", limit, limit)
posix.setrlimit("as", limit, limit)
gra = ("fooo"):rep(1e8)
print("still alive")

That script will take up about 2 GB of RAM and will not get killed.

bundling gnulib into release tarballs

Hi,

I really wonder why gnulib is not bundled within release tarballs, besides the obvious question why luaposix is relying on gnulib anyway - but that is a different topic. The thing that bothers me more is why you are relying on cloning a remote git repository before being able to build from a release tarball? Why aren't you bundling gnulib within release tarballs, like 99.99999% of other projects that rely on that infamous piece of bloat and redundancy?

Here are some points to think about:

1. I think it is not quite uncommon that automatized build environments are building stuff within a chroot sandbox which has no network connectivity.
2. building from a release tarball also means that you will have the ability to reproduce a build later, but how is that going to work if the sources can vary depending on the mood of gnulib developers?
3. While looking at the 'bootstrap' script I have seen an option '--gnulib-srcdir' which is good to have, but it doesn't really solve point 2.
4. An author/maintainer knows best what versions of 3rd. party components he/she is using will work, and if there are no tagged releases of such a component it is wise to include exactly the version it was developed with! (Btw, I am by far not a fan of including every piece of 3rd. party library into sources!)

Short - It would be very neat if you could include exactly the version of gnulib within release tarballs you have developed/tested with.

Cheers,
Chris

Specs for fork() are not quite right

Hello,

I did some experiments with specs and there is something not really right about fork() specs:

This spec should complain and it does:

  - describe fork:
    - it copies itself to a new child process:
        expect (1).should_be (2)  -- FAILS
        process, status = fork (), 67
        if process == P_CHILD then
          ... -- other expectations in "child"
        else
          ...
        end

This spec should complain too but it doesn't:

  - describe fork:
    - it copies itself to a new child process:
        process, status = fork (), 67
        if process == P_CHILD then
          expect (1).should_be (2)  -- DOESN'T FAIL?
          ... -- other expectations in "child"
        else
          ...
        end

Is it a problem of fork(), specl or just this particular test case?

Mistake in doc comment

The usage example for posix.chdir seems to be incorrect. It's exactly the same as the one for posix.access.

Source line: https://github.com/luaposix/luaposix/blob/master/lposix.c#L713

Unresolved global in posix.lua

The function pipeline in posix.lua calls list.sub(), but list is nil.
I think replacing it with a 2-liner would be best here (instead of creating a dependancy).

Regards,
Bernd

posix.pipeline: please review

I've just added a function posix.pipeline to allow a pipeline of processes to be run simply from Lua, including both shell commands and Lua functions.

Please take a look and see what issues there are with the code. Obvious things to consider:

1. Should it handle some signals? Currently it doesn't, reasoning that Lua is not a shell, so if the signal ends up killing the calling process, that's fine; but that's not ideal for use at the REPL. (See e.g. http://www.cons.org/cracauer/sigint.html )
2. Should it die or return some error code on error? die-ing seems the logical thing to do to "return" from a process, but would it be nice to have some way to distinguish an error inside the pipeline function from errors in the called processes?
3. Is it really necessary to fork as much as it does? I think so, but I'm not entirely sure. In particular: the child shell processes can't use os.execute, as system(3) blocks SIGCHLD. It might seem unnecessary to fork again when the sub-process is actually a Lua function, but in fact it is, as otherwise it's not run in parallel, risking the pipeline blocking. But I'm not 100% convinced that it's necessary to fork AGAIN when there's another stage to the pipeline.
4. Any other hacks needed/not needed? For example, there are lots of calls to posix.close to make sure SIGPIPE will be delivered as per signal(7). The original stdout is saved and then restored at the end, but strictly that's only needed at the top level (I think?). Maybe the function could be restructured to avoid the nasty "if t2..." blocks.
5. What other features would be nice? The most obvious is a way to get the output of the last stage. Feeding input to the first stage is easily done by prepending an extra Lua function to the list, but owing to the one-way nature of pipes, and the fact that we're using fork here, it's harder to get data out: I propose to write a wrapper to set up a pipe and add an extra process to the end of the list to return the last stage's stdout like io.lines. Another idea would be to somehow wrap functions so they can take stdin as an argument and write to stdout with return values; this would require designing a calling convention that works with as little modification required to existing code as possible. For example, provide a pattern to split input into arguments, and specify a separator to string.join the results when writing them out.

I think this is a really interesting feature (I've been meaning to implement it for months) to make it easier to write shell scripts in Lua. I don't know of a similar feature in other scripting languages, either. In general I think it should work "just like" the shell, and extra functionality should be wrapped on top. But getting it right is tricky both in terms of robustness and exact API, so I'm very open to suggestions.

Forgot to check in some files?

$ make                                                                     
(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /Volumes/Home/Devo/luaposix--github--0/build-aux/missing autoheader)
rm -f stamp-h1
touch config.h.in
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
make  all-recursive
Making all in lib
make  all-recursive
  CC       dummy.lo
  CCLD     libgnu.la
/usr/bin/ranlib: file: .libs/libgnu.a(dummy.o) has no symbols
ranlib: file: .libs/libgnu.a(dummy.o) has no symbols
ranlib: warning for library: .libs/libgnu.a the table of contents is empty (no object file members in the library define global symbols)
  CC       posix_c_la-lposix.lo
  CCLD     posix_c.la
  CC       lcurses.lo
  CCLD     curses_c.la
/usr/bin/perl make_lcurses_doc.pl
make[2]: *** No rule to make target `docs/index.html', needed by `all-am'.  Stop.
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Support for message queues

Looks like there is no support for <sys/msg.h> functions: msgget()/msgctl()/msgsnd()/msgrcv()

According to my man pages these are parts of POSIX.1-2001.
Any plans to support message queues?

Thanks!

Running tests on local directory without 'make install'

just curious: the test scripts all require the posix module to be loadable by the default lua package search path; thus i'm not able to run the tests without doing the install. How do others handle this, do you run make install after each modification while testing?

Code behaves incorrectly under gcc 4.7

Macro definition

define LPOSIX__STR_1(_s) (#_s + 1)

define LPOSIX_STR_1(_s) LPOSIX__STR_1(_s)

is incorrectly used inside arrays initializers (lposix.c)
"static const luaL_Reg R[] =
{

define MENTRY(_s) {LPOSIX_STR_1(_s), (_s)}

MENTRY( P_exit      ),
MENTRY( Pabort      ),

...
"

C standard (http://c0x.coding-guidelines.com/6.7.8.html) says: "All the expressions in an initializer for an object that has static storage duration shall be constant expressions or string literals."

Due to this issue, luaposix library behaves incorrectly under gcc 4.7.

posix.pipeline doesn't restore stdout properly

See https://savannah.gnu.org/patch/index.php?8007 for a demonstration of the problem (in an editor, using posix.pipeline messes up the terminal).

The advice given here: http://stackoverflow.com/questions/11042218/c-restore-stdout-to-terminal is exactly what posix.pipeline does (independently!), so I'm not sure what the problem is.

Building on freebsd and hurd

Hello, I've uploaded v29 on Debian and the freebsd and hurd port failed to compile.
Some flags are not available in these systems, so I #ifdef them out.
You can find the patches at the following url (look for the version in "sid"):
http://patch-tracker.debian.org/package/lua-posix/
Best,
Enrico Tassi

GPLv3 licensing issues

FYI -

Although the license states that this module is licensed under a flexible MIT/BSD license, as built, it include GPLv3 sources. This is a direct result of using the autoolize 'bootstrap' script to generate the configure script. The 'bootstrap' script creates a file in "lib" called dummy.c that includes the GPLv3 license and is summarily compiled and linked to the module. As a result, this module is now GPLv3 for all intensive purposes. This is very unfortunate and I suspect not the intent. The 'dummy.c' file is a bogus file that is only there to make the linker on MacOSX, FreeBSD, and SunOS happy. The contents are either the definition of an unused typedef or the declaration of an unused int:

ifdef __sun

/* This declaration ensures that the library will export at least 1 symbol. */
int gl_dummy_symbol;

else

/* This declaration is solely to ensure that after preprocessing
this file is never empty. */
typedef int dummy;

endif

It's clear that this should be easy to remove and I believe it should be removed so that the commercially friendly MIT/BSD license can be maintained. One fix I would propose is to remove and/or re-write the file after 'bootstrap' runs to eliminate this issue.

Sorry for being picky, but without this change, it's makes it impossible to use this module in commercial projects where I believe many people already use it. Is this something you could fix?

configure doesn't have any options to specify lua include paths, or find debians

As a result, luaposix seems unbuildable on debian derived distros, which needs -I/usr/include/lua5.X added to the include path. Or maybe I just can't figure out how to build it, but I read the MX macros, and didn't see any searching for lua header paths.

For anybody looking for a work-around for this, this seem to work:

cp /dev/null config.h
gcc -Wall -O2 -fPIC -fno-common -shared -I/usr/include/lua5.1 -I. -DVERSION='"5x"' -D_GNU_SOURCE -o posix_c.so lposix.c -lrt

Have poll() always add revents field to fdset?

Poll only adds the revents table to file descriptors for which an event has occured. This makes checking the poll() result cumbersome, because the check should always first check if the revents table exists before checking the event type.

Would it be possible / desirable to have poll() always add the revents for each file descriptor?

Setting argv[0] of an exec'd process separately from the command used to run it

I need to set the apparent name of a process to a different string from the command used to run it. There are various reasons one might want to do this; mine is that I'm translating the "cw" package, which wraps various standard commands to color their output, into Lua, so it wants its wrappers to appear with the same name as the original command (ps, df, du &c.).

Currently, posix.exec[p] hardwire argv[0] to the command (first argument). The current syntax is:

posix.exec (command, arg1, arg2, arg3, ...)

This is also unfortunate, as typically the arguments will be constructed in a list, so you end up having to call:

posix.exec (command, unpack(arglist))

I propose therefore to deprecate this syntax (adding a note to remove it in, say, a year's time), and add support for the new syntax:

posix.exec (command, arg_table)

A typical call would then therefore be:

posix.exec (command, {arg1, arg2, arg3, ...})

and if (like me) you want to change argv[0], then it's easy:

posix.exec (command, {[0]="name", arg1, arg2, arg3,...})

...and I would modify the internal runexec function to check indices of the table from 0..#t rather than 1..#t as at present.

If this sounds OK, I'll implement it.

Build Failure on OSX 10.6.8

Buiding makes this error:

lposix.c: In function ‘luaopen_posix_c’:
lposix.c:2078: error: ‘SIGPOLL’ undeclared (first use in this function)
lposix.c:2078: error: (Each undeclared identifier is reported only once
lposix.c:2078: error: for each function it appears in.)
make[2]: **\* [posix_c_la-lposix.lo] Error

signal.h looks like this on this system:

# if  (defined(_POSIX_C_SOURCE) && !defined(_DARWIN_C_SOURCE))
# define SIGPOLL 7   /\* pollable event ([XSR] generated, not supported) */
# else   /\* (!_POSIX_C_SOURCE || _DARWIN_C_SOURCE) */
# define SIGIOT  SIGABRT /\* compatibility */
# define SIGEMT  7   /\* EMT instruction */
# endif  /\* (!_POSIX_C_SOURCE || _DARWIN_C_SOURCE) */

_DARWIN_C_SOURCE is enabled by normal configure script in config.h

Simply commenting out the setting of SIGPOLL helps.

Please remove LGPL code ASAP!

This file:

https://github.com/rrthomas/luaposix/blob/master/strlcpy.c

is under LGPL license. You are violating terms of the license by releasing luaposix under MIT.

This is also a problem for developers with strict no-GPL policies like us.

Please do remove LGPL code ASAP and make a new release. Contact me privately if you need any assistance with that that.