| Age | Commit message (Collapse) | Author |
|---|
|
- s/environnement/environment/
- s/interger/integer/
MFC after: 3 days
|
|
flua is a standalone third-party component that deserves its own
package. In particular, this means things can use flua without
having to depend on FreeBSD-utilities, which will be useful as
more base utilities use flua.
This saves ~500kB in FreeBSD-utilities for systems which don't
need flua.
MFC after: 3 days
Reviewed by: kevans
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53161
|
|
Local tree pollution let this escape. *sigh*.
Pointy hat: kevans
Pointy hat: kevans
Pointy hat: kevans
Fixes: 9c7db0931d486ce ("flua: move lposix back into flua for now")
|
|
The real luaposix is structured differently, and our builtin version
tends to model that in its own special way. Build it back in until we
get the shlib model just right to unbreak nuageinit, among other things.
This is a partial revert of the below-referenced commit; the other two
modules are simple, though, and were accurately split out.
Reported by: markj
Fixes: b11a5709ec2b6 ("flua: kick out the remaining builtin modules")
|
|
Bootstrap flua has some magic now to handle modules by building them in
and discovering them via linker sets. This is slightly cleaner than
always building them in and baking them into loadedlibs for both
bootstrap and system flua.
Adjust the stand build now that these three libs have their own new
homes.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51891
|
|
This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED. As a result, we also
cannot dlsym(), so we can't really discover the names of our newly
builtin modules. Instead, just build out a linker set with all of our
luaopen_*() functions to register everything up-front.
Building in all of the modules isn't strictly necessary, but it means
that we have an example of how to add a bootstrap module everywhere you
go and one doesn't need to consider whether bootstrap flua can use a
module when writing scripts. On my build machine, the consequence on
our binary size is an increase from around 1.6M -> 1.9M, which isn't
really that bad.
.lua modules can install into their usual path below $WORLDTMP/legacy
and we'll pick them up automagically by way of the ctor that sets up
LUA_PATH early on.
This re-lands bootstrap module support with a more sensible subset, and
after having verified that it cross-builds fine on macOS and Linux -- we
cannot do libfreebsd on !FreeBSD because it's more system header
dependant. We also need to bootstrap libmd to bring in libhash, and
libucl + libyaml.
Reviewed by: bapt, emaste (both previous version)
Differential Revision: https://reviews.freebsd.org/D51890
|
|
This reverts commit 1953a12ee2cde1afacb3e3f7612d89695c96e04f, because it
cannot work at all on macOS without more work, at a minimum. We use
linker sets for module discovery, but we don't have a version of this
that works for mach-o at the moment.
|
|
This reverts commit 80ada959004c4386880e47b11618f8abfc2d80e1, because
bootstrap flua is about to get backed out.
|
|
This reverts commit 31320402472394af57eb3a36bee7f944117ca0ed, because
bootstrap flua is about to get backed out.
|
|
Other systems don't have jail support, and we won't be using it anyways.
|
|
Bootstrap flua has some magic now to handle modules by building them in
and discovering them via linker sets. This is slightly cleaner than
always building them in and baking them into loadedlibs for both
bootstrap and system flua.
Adjust the stand build now that these three libs have their own new
homes.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51891
|
|
This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED. As a result, we also
cannot dlsym(), so we can't really discover the names of our newly
builtin modules. Instead, just build out a linker set with all of our
luaopen_*() functions to register everything up-front.
Building in all of the modules isn't strictly necessary, but it means
that we have an example of how to add a bootstrap module everywhere you
go and one doesn't need to consider whether bootstrap flua can use a
module when writing scripts. On my build machine, the consequence on
our binary size is an increase from around 1.6M -> 1.9M, which isn't
really that bad.
.lua modules can install into their usual path below $WORLDTMP/legacy
and we'll pick them up automagically by way of the ctor that sets up
LUA_PATH early on.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51890
|
|
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
|
|
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D50176
|
|
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
|
|
Sponsored by: The FreeBSD Foundation
|
|
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: 442e0975ee4b3 ("Consolidate md4 implementations written in C")
Fixes: c2caf3b3313fe ("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
|
|
|
|
When moving the freebsd.sys.linker sources the installation path
was lost.
Fixes 7899f917b1c0ea178f1d2be0cfb452086d079d23
|
|
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
|
|
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D46569
|
|
This allows one to invoke uname from lua scripts.
Reviewed by: bapt, kevans, emaste
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D42017
|
|
This is a residual of the $FreeBSD$ removal.
MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix
|
|
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
|
|
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
|
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
|
Remove /^/[*/]\s*\$FreeBSD\$.*\n/
|
|
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
|
|
|
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
Notes:
svn path=/head/; revision=364227
|
|
There are some logistics issues that need to be sorted out here before we
can actually allow this to work.
Notes:
svn path=/head/; revision=364226
|
|
Export symbols from flua, and enable dlopen.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26059
Notes:
svn path=/head/; revision=364222
|
|
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
Notes:
svn path=/head/; revision=362477
|
|
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
Notes:
svn path=/head/; revision=359455
|
|
This is a nicer experience when attempting to run ad-hoc lua bits in the
flua REPL.
PR: 245121
MFC after: 1 week
Notes:
svn path=/head/; revision=359453
|
|
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
Notes:
svn path=/head/; revision=359045
|
|
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
Notes:
svn path=/head/; revision=358960
|
