| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
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.
|