Random snippets, random thoughts, random things.


- Paper notebook

Open all files in a directory in vim splits

vim -o $(ls -1)
vim -o *

Run local script on remote host

ssh foo < bar.sh

Simple parallelization of tasks

If you want to parallelize commands `foo`, `bar`, and `baz`, but you need to block until they all complete, you can:
foo &
bar &
baz &

POSIX shell key-value store backed by the filesystem

POSIX shells lack syntax for dictionary data structures, so if you need something that works everywhere you can leverage the filesystem to read and write stuff with surprisingly decent syntax
db=$(mktemp -d)
trap "rm -rf $db/" EXIT INT HUP TERM

# Writing
echo "1" > $db/foo
echo "2" > $db/bar

# Reading
foo=$(cat $db/foo)
bar=$(cat $db/bar)
If you are familiar with POSIX shell scripting this should feel like home to you.

One-line basic HTTP GET

If you need to issue a very simple HTTP GET request from a constrained environment where you won't find curl, you can write
printf 'GET / HTTP/1.1\r\nHost: example.com\r\n\r\n' | nc example.com 80

Find which well-known service a port is servicing

cat /etc/services | grep "3306/tcp"
mysql		3306/tcp

The only shell command that returns itself

cat /proc/self/cmdline

Container suicide

At the end of the day, a container is just a process running on a host machine with some pid P. However from the perspective of the container this process is the root process with pid 1, either some init process (LXD) or an application (Docker). Thus killing process with pid 1 will kill the container on the host.
kill 1

Enable fast internet

apt install speedtest
(while true; do speedtest; sleep 120; done) &

git bisect

I just learned that with git bisect you can give git (1) a bad commit/branch, (2) a known good previous commit/branch, (3) a command to test said “goodness” (e.g. passing unit tests, passing linting, etc) and git will do a binary search between those commits, narrowing down the window at every step trying to find the commit that introduced the problem.

Say you are implementing a new feature in branch feature/someNewFeatureWip and you realize after some 7 commits in this branch that you introduced a bug. If you have tests that catch that bug you can find the culprit commit quite easily:

$ git bisect start
$ git bisect bad feature/someNewFeatureWip                          # (1)
$ git bisect good develop                                           # (2) 
$ git bisect run sh -c 'flutter build && flutter test && ...'       # (3)

Of course, for best results you need good modular commits and good extensive testing.

Otherwise you can still use git bisect to manually mark commits as good and bad (to help you do the binary search in your head) and test manually rather than automatically, which is all you can do in some cases when the testing isn't there.