Invoking vimto goes via the -exec flag:
go test -exec vimto ...
This has the downside of running into the special rules that go test has for
arguments. For example, the following doesn't work:
go test -exec vimto -vm.kernel /path -run Foo ./bar
go test stops parsing the command line args after -vm.kernel which leads to
very confusing behaviour. The fix is to always add arguments to the end of
the command line, but that is hard to remember and impossible to enforce
from our side. The user has to learn by error, which isn't great.
Additionally, there is no way to provide the user feedback as to what vimto
is doing, since go test buffers all output. For example, it might look like
the program is hanging while we are downloading a large OCI image.
Fix this by changing the way vimto is invoked. Instead of being called by go
test we call go test instead. The equivalent of the example above is now:
vimto -kernel /path -- go test -run Foo ./bar
A nice side effect is that flags are less awkward to write out.
give indication of docker pull progress
Add a progress bar to indicate that a docker image pull is going on. This
avoids confusion if the pull takes a long time.
fix restoring tty settings on ctrl-c
qemu changes some settings when it detects that stdin is a TTY.
Specifically, it turns off echoing. On shutdown it restores the old
settings. However, this doesn't work when the process is interrupted with
ctrl-c because we react to os.Interrupt by killing the qemu process. This
means that there is no time for qemu to restore settings. The result is a
broken shell that you can type into, but which doesn't echo anything.
Fix this by "forwarding" ctrl-c to qemu by sending it os.Interrupt and
giving it a grace time to shut down. This allows restoring the terminal
setting.
simplify invocation
give indication of docker pull progress
fix restoring tty settings on ctrl-c