| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The C implementation of el_semicolon in execline only reads one
argument at a time and returns an index into the rest of argv.
This makes sense for the usual application of programs using it, which
is just reading a few arguments and a block or two, and then executing
into `prog`. `prog` could be anything really, including additional
blocks.
The new `el_semicolon_full_argv` function exports the previous
behaviour of parsing the whole thing.
As a nice side-effect, we return the rest of argv in-place.
|
|
|
|
|
|
|
|
|
|
|
| |
el_exec: wraps the various execve wrappers in skalib that are useful
for writing execline-like utils. currently only `xpathexec0` is
supported, which execs into the argv you give it or errors with the
right error if file not found.
el_substitute: execline argv substitution! Wraps the execline
function, so it will behave exactly the same as the existing execline
utils, like `importas`.
|
| |
|
| |
|
|
|
|
|
|
| |
rlwrap has to do magic recognition, which breaks in most cases.
We can just print a prompt before the first and after each consecutive
command. Seems to work wonderfully.
|
| |
|
|
|
|
| |
Forgot the cat after I added forstdin.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
In some cases (especially with `runblock`), the arguments need to be
accessible as environment variables, so we need a way to pass that to
execline.
|
|
|
| |
This makes ./foo work.
|
|
|
|
|
|
|
| |
This has been upstreamed to nixpkgs proper, as a C wrapper script, in
https://github.com/NixOS/nixpkgs/pull/71357
So we don’t even need bash to run execline anymore :P
|
|
|
|
|
|
| |
EXECLINE_STRICT does not apply to the `execlineb` command itself, so
we don’t get any errors if the nesting is incorrect. `-W` does set it
for `execlineb` however.
|
| |
|
|
|
|
|
| |
similar to writeScript, but writes an execline instead. Should be
upstreams to `lib.writers` sometimes.
|
|
|
|
|
|
|
|
| |
It’s conventional that these tools have the form
tool name options data
so we should adhere to that.
|
|
|
|
|
| |
We can auto-escape execlines correctly if we model them as nix-style
lists, so we shoud certainly do so. It also helps abstraction.
|
| |
|
| |
|
|
|
|
|
| |
Reference files in `bin` outputs for a derivation as an attribute set,
with renaming capabilities.
|
|
|
|
|
|
| |
Improves the “execline experience” and adds some basic tests.
The idea is that the final result doesn’t use coreutils and provides a
feasible alternative to bash-based tooling.
|
|
* runExecline: like runCommand, but a lot more lightweight
* symlink: symlink a given list of links together
* importer: a small DSL to “import” “modules” into a build context
Some highlights:
* runExecline does not use any stdenv (apart from the `execline` build)
* symlink uses netstrings to pass correct fields into the derivation
* no use of bash, everything uses execline.
|