This allows us to do things like:
```
local fp = assert(fbsd.exec({"ls", "-l"}, true))
local fpout = assert(fp:stdout())
while true do
local line = fpout:read("l")
if not line then break end
print("Read: " .. line)
end
fp:close()
```
The makeman lua rewrite will use it to capture `make showconfig` output
for processing.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D50539
This gives us some way to be able to write to stdin if we want to, or
as a future improvement, will allow us to extract stdout from the
process. The handle is setup to close and waitpid() on close/gc so that
existing users wouldn't necessarily leak for the lifetime of the script
if they weren't adopted to the new model.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D50538
Additionally, there's no way to get to the end without a valid
stdin_pipe[1] at the moment, so don't check for it. stdin_pipe[0] is
closed earlier, as the parent shouldn't need the read-side of the pipe.
While we're here, also free the file actions earlier and on error --
they're not necessary once posix_spawnp() has returned.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D50537
The posix module is subdivided according to C headers; for instance,
posix.unistd contains routines available from unistd.h, such as
chown(2).
A quirk of our implementation is that each of the modules is a direct
entry in the global table. That is, there is no "posix" table.
Instead, "posix.foo" and "posix.bar.baz" are both top-level tables.
This is surprising and goes against Lua's shorthand of using "." to
access keys in a table. lua-posix also doesn't work this way.
Rework things so that "posix" and "posix.sys" are proper tables.
Existing flua code which uses require() to bind posix submodules to a
name will be unaffected. Code which accesses them directly using
something like _G["posix.sys.utsname"].uname() will be broken, but I
don't think anything like that exists. In particular, it is now
possible to call posix.sys.utsname.uname() without any require
statements.
Reviewed by: imp, bapt
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D51158
The implementation of chown() in the posix module handles user and group
names as well as numeric IDs. When resolving names, be sure to use
reentrant lookup functions rather than assuming it's safe to clobber the
internal buffers used by getpwnam() and getgrnam().
Fix some style nits while here.
Reviewed by: imp, bapt
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D46555
This matches the interface of lposix, although I do wonder why they went
with execp rather than execvp for the function name here.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D50177
The key insight here is that the luaL_check*() and luaL_opt*() functions
will happily take indexes that are larger than the stack top and print a
useful error message.
This means that there is no need to check if too few arguments have been
received prior to checking the types of individual arguments.
This patch also replaces a couple reimplementations of luaL_opt*()
functions with the luaL helpers.
References: https://www.lua.org/manual/5.4/manual.html#4.1.2
Reviewed by: emaste, kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D50273
Flua is a minimal Lua interpreter integrated into the FreeBSD base
system. It is intended for internal use and is not designed for
general-purpose scripting or use by third-party applications, and was
originally intentionally undocumented.
There have been questions about its purpose, and questions about the
available functionality from internal users, so provide a minimal man
page including these details.
Reviewed by: kevans, Isaac Freund <ifreund@freebsdfoundation.org>
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49835
Each one is an arbitrary string associated with a jail. It can be set
upon jail creation or added/modified later:
> jail -cm ... meta="tag1=value1 tag2=value2" env="configuration"
The values are not inherited from the parent jail.
A parent jail can read both metadata parameters, while a child jail can
read only env via security.jail.env sysctl.
The maximum size of meta or env per jail is controlled by the
global security.jail.meta_maxbufsize sysctl. Decreasing it does not
alter the existing meta information.
Each metadata buffer can be handled as a set of key=value\n strings:
> jail -cm ... meta="$(echo k1=v1; echo k2=v2)" env.1=one
> jls meta.k2 env.1 meta.k1
While meta.k1= resets the value to an empty string, the meta.k1 without
the equal sign removes the given key.
Relnotes: yes
Reviewed by: jamie
Tested by: dch
Sponsored by: SkunkWerks GmbH
Differential Revision: https://reviews.freebsd.org/D47668
The fnmatch function matches a string against a shell-style filename
pattern. It is a complex function and cannot easily be implenented
using regular expressions. Adding fnmatch to flua increases the amd64
binary by less than 1 KB.
Approved by: markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D46849
- Provide a sys/md4.h in the cross-build environment to fix bootstrap
of libmd.
- flua now exposes WTRAPPED which isn't incredibly common- make it
conditional, we probably won't be using it in any bootstrap context
any time soon.
Fixes: 442e0975ee ("Consolidate md4 implementations written in C")
Fixes: c2caf3b331 ("flua: posix: add more useful functions [...]")
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.
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D39083
Add bindings for kenv(2) right now only get() has been created
it allows do dump into a key/value table the kernel environement if
no argument is passed, or it returns the value associated to the
provided key.
Reviewed by: imp, kevans, markj
Accepted by: imp, kevans
Differential Revision: https://reviews.freebsd.org/D46654
Follow the path of what is done with bsnmp, build the modules along
with the main binary, this allows to build the modules at a moment
where all needed libraries are already built and available in the
linker path instead of having to declare all the libraries which a
flua module will be linked to in _prebuild_libs.
Discused with: markj
Reviewed by: markj, jrtc27, kevans, imp
Accepted by: kevans, imp
Differential Revision: https://reviews.freebsd.org/D46610
This module is bundled into flua, it only provides for now the exec
function. The point of the function is to be able to execute a program
without actually executing a shell.
to use it:
fbsd.exec({"id", "bapt"})
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D41840
The main difference with the chown in luaposix, is that it checks
and reports if a user or a group do exist when a string is passed
as arguments
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D37479
This eliminates a lot of stat() calls that happen when lualoader renders the
menu with the default settings, and greatly speeds up rendering on my
laptop.
ftype is nil if loader/loader.efi hasn't been updated yet, falling back to
lfs.attributes() to test.
This is technically incompatible with lfs, but not in a particularly
terrible way.
Reviewed-by: cem
MFC-after: 4 days
Differential Revision: https://reviews.freebsd.org/D27542
flua does have some specific bits that will include luaconf.h, but the
definition of LUA_USE_DLOPEN for those won't matter. This belongs in liblua
instead.
To expand on my previous commit, which was a little sparse with details,
it's not really safe to allow LUA_USE_DLOPEN with host lib paths being used.
The host system could have an entirely different lua version and this could
cause us to crash and burn.
If we want to revive this later, we need to make sure to define c module
paths inside OBJDIR that are compiled against whatever version we've
bootstrapped.
Pointy hat: kevans
libucl comes with a Lua library binding. Build it into flua.
This lets us parse/generate config files in the various formats supported by
libucl with flua. For example, the following script will detect the format of
an object written to stdin as one of UCL config, JSON, or YAML and write it to
stdout as pretty-printed JSON:
local ucl = require('ucl')
local parser = ucl.parser()
parser:parse_string(io.read('*a'))
local obj = parser:get_object()
print(ucl.to_format(obj, 'json'))
Reviewed by: kevans, pstef
Approved by: mmacy (mentor)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D25009
The bootstrap flua should not be used for REPL-like activities; exclude it
to save the dependency on libedit and not waste time with it.
X-MFC-With: r359453
The new liblua will be used in a forthcoming import of kyua.
Reviewed by: kevans
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24090
Lua does not provide a native way to change the permission of a file.
Submitted by: Yang Wang <2333@outlook.jp>
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24036
FreeBSDlua ("flua") is a FreeBSD-private lua, flavored with whatever
extensions we need for base system operations. We currently support a subset
of lfs and lposix that are used in the rewrite of makesyscall.sh into lua,
added in r354786.
flua is intentionally written such that one can install standard lua and
some set of lua modules from ports and achieve the same effect.
linit_flua is a copy of linit.c from contrib/lua with lfs and lposix added
in. This is similar to what we do in stand/. linit.c has been renamed to
make it clear that this has flua-specific bits.
luaconf has been slightly obfuscated to make extensions more difficult. Part
of the problem is that flua is already hard enough to use as a bootstrap
tool because it's not in PATH- attempting to do extension loading would
require a special bootstrap version of flua with paths changed to protect
the innocent.
src.lua.mk has been added to make it easy for in-tree stuff to find flua,
whether it's bootstrap-flua or relying on PATH frobbing by Makefile.inc1.
Reviewed by: brooks, emaste (both earlier version), imp
Differential Revision: https://reviews.freebsd.org/D21893
