flua: lposix: add more useful functions for general purpose scripts

[kevans]

Summary

unistd:

• _exit
• close
• fork
• getpid
• pipe
• read
• write

libgen:

• basename, dirname

stdlib:

• realpath

These are sufficient for a number of real world scenarios. In our first
application of them, we use the libgen+stdlib additions to grab the
script dir based on argv[0]. The unistd assortment is then used to
outsource a bunch of work to forks and report back to the main process.

[kevans]

Use allocf, matches lua's internal naming

[bapt]

I don't understand why you need lposix_alloc and lposix_free at all vs direct call to free and malloc?

libexec/flua/modules/lposix.c

2–4

Why this extra line?

156

Why changing style?

[emaste]

libexec/flua/modules/lposix.c

5

care to add SPDX headers while here?

[kevans]

In D39083#898199, @bapt wrote:

I don't understand why you need lposix_alloc and lposix_free at all vs direct call to free and malloc?

Better form for a lua lib, though this one shouldn't see the light of day since it's a reimplementation of lposix so I could just simplify it.

[emaste]

overall looks good

libexec/flua/modules/lposix.c

107

is it ok to call this if inpath == NULL?

590

is it typical to use n for this? unless it's std lua convention maybe something more descriptive like narg?

[kevans]

Address comments; fix return consistency; a couple of missed return (3) and
one return (1) that should've been 3

[kevans]

libexec/flua/modules/lposix.c

107

D'oh, that should have had a return (3) otherwise the return value ends up being a bit nonsensical (and we leak two stack entries, iirc).

[imp]

So this looks generally good, modulo some error messages about having args having the function name and some not.

libexec/flua/modules/lposix.c

5

... and remove the boilerplate?

169

Close vs pclose in error message.

198

No name here? But close had one. Here and elsewhere

468

Why pclose?