| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Recent versions of s6-portable-utils no longer include s6-test
which was deprecated in favor of eltest which supposedly has the
same interface.
I've not tested this commit very thoroughly, but my system now builds
again with recent nixpkgs commits (I think I dependended on s6-test
via the rust writer via nman).
cc @Profpatsch
|
| | |
|
| |
|
|
|
| |
It’s always a mistake to forget a block here, so this will give a
better error message.
|
| |
|
|
| |
It’s not worth the indirection.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
calling `execlineb -c` has unfortunate quoting issues, cause for
cornercases like arguments that contain spaces or `"` the result would
be a completely broken command line.
Instead, let’s do our own block construction in a small rust
program (for speed). I tried implementing it in bash first but even
prepending spaces to a string is a complete waste of time in that
language.
|
| |
|
|
|
|
| |
testRustSimple wouldn’t work with all the rust functions, so let’s
just use it internally and expose the tests via the conventional
`doCheck` attribute instead.
|
| | |
|
| | |
|
| |
|
|
| |
Upstream is deprecating `stdenv.lib`, so let’s do the same.
|
| |
|
|
|
|
|
|
|
|
|
| |
skarnet thought it would be wise to completely change the skalibs
exec function interface without any backwards compat, so here we are.
Have to reverse the code a bit, because `xmexec0` is a recursive
`#define` pointing to `xmexec0_af`.
`record-get` gets a rust treatment, it doesn’t really need the C
interface just to exec into prog.
|
| |
|
|
|
|
|
|
|
| |
Small tool which takes a block of nix options that should produce a
script to run, and then calls the script with the rest of argv
e nix-run { -A foobar } a b c
calls `nix-build -A foobar && ./result a b c`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since the goal of using `e` with argv is interactive execution of
block-style commands from the command line, the use of { and } for
blocks is sub-optimal, since bash (and ostensibly also fish) interpret
them as metacharacters and assign some semantics.
[ and ] on the other hand are not taken (apart from the `[`
executable, which is only relevant in command position and can always
be replaced by the `test` command). So we translate a stand-alone "["
argument to "{" and the same for "]"/"}", giving us a transparent
block syntax.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Often times I want to execute “block-style” programs directly, but it
is rather inconvenient to type out `execlineb -c "…"` every time, plus
-c wants the argv as a single string instead of an argv.
The alternative, using the block representation with leading spaces,
is even less ergonomic.
So instead of
execlineb -c "nix-run { -A pkgs.profpatsch.e ~/vuizvui } echo hello"
or even
nix-run ' -A' ' pkgs.profpatsch.e' ' /home/me/vuizvui' '' echo hello
I can now write
e nix-run { -A pkgs.profpatsch.e ~/vuizvui } echo hello
and it will work as expected (provided your shell expands inside {}
blocks, which bash does but fish doesn’t for some reason).
If no argument is passed, e falls back to opening a shell prompt.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
