I did catch myself stop watching YT series like "here's another bigger monitor" or whatever. Idk we all have our thing I guess. I was getting sucked into camera gear for a bit.
I'm using this[1] and I love it. Adding 1 column of spacing between two hands is real game changer. I've tried Colemak and Workman before but I found qwerty-wide to be more comfortable than both of them. It's also much easier to learn, especially if you're Vim user.
That’s an interesting solution! As someone who likes a wider keyboard stance this makes a lot of sense to me, and I think it’d work well with an ISO layout too.
I guess the projects you mentioned are complementary, in that TAP as I understood it merely specs the output stream/protocol that a test run is expected to produce and isn't limited to testing shell scripts, whereas cram/mdx appears more like a user acceptance test convention specifically for shell script code as component-under-test, much in the spirit of "behavioural" testing a la jBehave.
just want to clarify that the program-under-test in cram can be written in anything, as long as it's executable and produces some outputs (stdout, stderr (or any other file descriptor, really), files, exit code). right now i'm using cram to test a program written in F#.
it's true that cram shines in tests for programs written in sh/bash/zsh, where you can output the command lines your PUT consists of (while | instead of) running them and then have cram verify that your program composes expected commands.
git-pimp.zsh is an example of an early approach: it runs its commands through a helper which uses $GIT_PIMP_CHATTY and $GIT_PIMP_DRYRUN to optionally output the given command line and whether to actually perform it, respectively. the helper is a function called "o" ([o-impl]) which makes the code look a little like a bullet list ([o use]).
[0120-output.t] sets git-pimp to skip execution of `git mailz` and `review-files` invocations, and echo any `git format-patch`, `git mantle`, ... invocations (regardless of whether they're dryrun or actually executed).
`o` was a stepping stone and inspiration to [fake]. this is an external command (as opposed to a shell function), so it cannot stub out shell functions, but it provides greater control over the behavior of mocked command lines. eg. one can mock out `rm -rf --no-preserve-root /` but leave all other uses of `rm` to the actual command, define any combination of exit codes and outputs of particular invocations or prefixes, or provide custom implementations for same. if you ever scripted any destructive, hardware- or network-dependent code (ip(8), fdisk(8), ssh(1)), [fake] can help write sort-of unit tests that do not require expensive setup. as always, mocks and stubs are dangerous, and i'm not claiming this is bullet proof, but it's still very useful.
reply