Random snippets, random thoughts, random things.
vim -o $(ls -1)
vim -o *
ssh foo < bar.sh
foo & bar & baz & wait
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.
curl, you can write
printf 'GET / HTTP/1.1\r\nHost: example.com\r\n\r\n' | nc example.com 80
cat /etc/services | grep "3306/tcp" mysql 3306/tcp
apt install speedtest (while true; do speedtest; sleep 120; done) &
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.