about summary refs log tree commit diff
path: root/pkgs/profpatsch/execline
Commit message (Collapse)AuthorAgeFilesLines
* pkgs/profpatsch/execline/runblock: check executable pathProfpatsch2022-01-071-5/+16
|
* pkgs/profpatsch/execline/runblock: check for empty blockProfpatsch2022-01-071-2/+8
| | | | | It’s always a mistake to forget a block here, so this will give a better error message.
* pkgs/profpatsch/execline: remove backtick nix abstractionProfpatsch2022-01-071-16/+0
| | | | It’s not worth the indirection.
* pkgs/profpatsch/e: add debug outputProfpatsch2022-01-071-3/+15
|
* pkgs/profpatsch/e: fix by rewriting in rust and execing into blockProfpatsch2021-07-272-14/+37
| | | | | | | | | | | 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.
* pkgs/profpatsch/write-rust: alwyas run tests by defaultProfpatsch2021-04-231-6/+5
| | | | | | 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.
* pkgs/profpatsch/el-semicolon: build and run tests using testRustSimplesternenseemann2021-03-311-10/+6
|
* pkgs/profpatsch/execline: add missing execline depProfpatsch2021-03-061-1/+1
|
* treewide: stdenv.lib -> pkgs.libProfpatsch2021-02-051-0/+0
| | | | Upstream is deprecating `stdenv.lib`, so let’s do the same.
* pkgs/profpatsch: adjust exec stuff to new skalibsProfpatsch2021-02-051-5/+16
| | | | | | | | | | | 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.
* pkgs/profpatsch: add nix-runProfpatsch2021-01-011-0/+16
| | | | | | | | | 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`.
* pkgs/profpatsch/e: translate [ and ] to block boundariesProfpatsch2020-12-281-9/+20
| | | | | | | | | | | | | 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.
* pkgs/profpatsch/e: allow passing a block-style argument as argvProfpatsch2020-12-281-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* pkgs/profpatsch: export toNetstring from the toplevelProfpatsch2020-06-291-6/+1
|
* pkgs/profpatsch/execline: change el_semicolon to only read one argProfpatsch2020-06-291-37/+80
| | | | | | | | | | | | | | | 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.
* pkgs/profpatsch/execline: add el_exec and el_substituteProfpatsch2020-06-284-19/+256
| | | | | | | | | | | 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`.
* pkgs/profpatsch/execline/el_semicolon: mark empty blocks as blocksProfpatsch2020-06-271-5/+10
|
* pkgs/profpatsch/execline: el-semicolon block parsingProfpatsch2020-06-222-0/+150
|
* pkgs/profpatsch/execline/e: better promptProfpatsch2020-01-261-12/+14
| | | | | | 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.
* pkgs/profpatsch/execline/e: add prompt colorProfpatsch2020-01-261-0/+2
|
* pkgs/profpatsch/execline/e: fix buffering problemProfpatsch2020-01-261-3/+0
| | | | Forgot the cat after I added forstdin.
* pkgs/profpatsch/execline/e: fix line splittingProfpatsch2020-01-261-6/+6
|
* pkgs/profpatsch/execline: add eProfpatsch2020-01-261-0/+23
|
* pkgs/profpatsch/execline: add runblockProfpatsch2020-01-261-0/+69
|
* pkgs/profpatsch/write-execline: add all argparsing commandsProfpatsch2020-01-261-2/+20
| | | | | | 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.
* escape: support pathsYorick2020-01-181-0/+1
| | | This makes ./foo work.
* machines/profpatsch,pkgs/profpatsch: rm `execlineb-with-builtins`Profpatsch2019-12-081-2/+2
| | | | | | | 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
* pkgs/profpatsch/execline: use -W instead of EXECLINE_STRICTProfpatsch2019-12-081-2/+1
| | | | | | 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.
* pkgs/profpatsch/write-exeline: fix ./escape.nix importProfpatsch2019-11-021-1/+1
|
* pkgs/profpatsch: writeExecline, writeExeclineLocalProfpatsch2019-10-021-0/+18
| | | | | similar to writeScript, but writes an execline instead. Should be upstreams to `lib.writers` sometimes.
* pkgs/profpatsch/runExecline: move to writeCommand formProfpatsch2019-09-263-62/+51
| | | | | | | | It’s conventional that these tools have the form tool name options data so we should adhere to that.
* pkgs/profpatsch/runExecline: move to listProfpatsch2019-09-264-45/+82
| | | | | We can auto-escape execlines correctly if we model them as nix-style lists, so we shoud certainly do so. It also helps abstraction.
* pkgs/profpatsch: export runExeclineLocal & run tests locallyProfpatsch2019-09-241-7/+19
|
* machines/haku: open less ports in firewallProfpatsch2019-05-161-0/+1
|
* pkgs.profpatsch: switch to different import schemeProfpatsch2018-09-222-21/+18
| | | | | Reference files in `bin` outputs for a derivation as an attribute set, with renaming capabilities.
* More execline experiments & testingProfpatsch2018-09-212-7/+119
| | | | | | 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.
* pkgs/profpatsch: WIP execline experimentsProfpatsch2018-07-253-0/+133
* 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.