SQLite is a great database (although often overlooked) with a bit of annoying CLI defaults.

For instance:

sqlite> select * from Album limit 10;
1|For Those About To Rock We Salute You|1
2|Balls to the Wall|2
3|Restless and Wild|2
4|Let There Be Rock|1
5|Big Ones|3
6|Jagged Little Pill|4
7|Facelift|5
8|Warner 25 Anos|6
9|Plays Metallica By Four Cellos|7
10|Audioslave|8

Three columns, two of them are numbers, and yet things are hard to read. Write .mode box in your ~/.sqliterc and things change dramatically:

sqlite> select * from Album limit 10;
┌─────────┬───────────────────────────────────────┬──────────┐
│ AlbumId │                 Title                 │ ArtistId │
├─────────┼───────────────────────────────────────┼──────────┤
│ 1       │ For Those About To Rock We Salute You │ 1        │
│ 2       │ Balls to the Wall                     │ 2        │
│ 3       │ Restless and Wild                     │ 2        │
│ 4       │ Let There Be Rock                     │ 1        │
│ 5       │ Big Ones                              │ 3        │
│ 6       │ Jagged Little Pill                    │ 4        │
│ 7       │ Facelift                              │ 5        │
│ 8       │ Warner 25 Anos                        │ 6        │
│ 9       │ Plays Metallica By Four Cellos        │ 7        │
│ 10      │ Audioslave                            │ 8        │
└─────────┴───────────────────────────────────────┴──────────┘

You can append .keys to the URL of your profile in order to receive the public keys you have on your account in a format to directly pipe it into ~/.ssh/authorized_keys:

curl https://github.com/<username>.keys | tee -a ~/.ssh/authorized_keys

Same goes for any GitLab instance.

Delete matched files

The most trivial one: find <path> [..] -delete (e.g. find . -name foo -delete).

However, depending on the OS -delete might not be available. In that case, see the next one.

Execute command with matched files

find <path> [..]  -exec <cmd> '{}' \;

is executed once for each matched file and the relative path to it is replaces '{}' and I always forget that \;, which might be omitted depending on a bunch of weird shell-isms (e.g. find . -name foo -exec rm -f '{}' \;).

If you want to call <cmd> exactly once (with caveats) with all the matched files passed as argument, add + at the end, but then '{}' should be right at the end of the command just before the +: find . -type f -name 'foo*' -exec rm -f '{}' +

Match files by modification time

find <path> [..] -mtime [+-]n

• n means modified precisely n days ago. This matches all files modified a week ago:
  find . -mtime 7

• +n means modified at least n days ago. This matches all files older than a week:
  find . -mtime +7

• -n means modified within the last n days. This matches all files older than a week:
  find . -mtime -7

By default it generates a bunch of passwords in columns. However with args it can be ustructed to generate one fairly long secret (64 characters):

pwgen 64 1

It has fairly good number of ways to configure what and how exactly to generate. The downside of this approach is that pwgen(1) is probably not installed by default on your machine.

/dev/urandom

Reading directly from /dev/urandom is the way to go on pretty much any UNIX these days (or fallback to /dev/random, although both are the same except on Linux) without having to install anything. The only question is how to make it output plain-text.

base64(1)

Arguably the easiest way if you don’t care that the only possible “special” characters besides letters and numbers are + and /:

base64 /dev/urandom | head -c64

tr(1)

If you need to define a strict alphabet to use for your secret:

cat /dev/urandom | tr -dc 'a-zA-Z0-9_!@#$%^&*()~+=-' | head -c64

openssl(1)

OpenSSL can also do the job with two possible outputs:

• hex: openssl rand -hex 42

• base64: openssl rand -base64 42 (uses = paddings)

The numeric argument is not characters, though.

gpg(1)

Because obviously GPG can do everything security related:

gpg --gen-random --armor 1 42

First number is “quality level” which is… complicated as with anything related to GPG anyways.

1. Prepare a single command that tries to reproduce the bug (e.g. script, test) off tree. Bisect is about to start jumping around, so it can’t be in the tree.

2. git bisect start: begin the bisect session.

3. git bisect bad: mark current HEAD as a bad commit (i.e. the bug is reproducible).

4. git bisect good <commit-ref>: some known commit in the past, where the bug does not exist.

5. You get dropped at a given commit. Try the command/test/script from step 1 and:

   • if the bug exists: git bisect bad
   • if the bug does NOT exist: git bisect good

6. Repeat until the initial bad commit is found.

7. git bisect reset.

git bisect run

Steps 5 and 6 can be automated with git bisect run if you can provide a script that exits with status code 0 when the chosen revision is good and something between 1 and 127 (except for 125) when the revision is bad.

The script should obviously be out of tree and executed with:

git bisect run <script_name> [<arg> ...].

nmap -sn 1.2.3.0/24

HOST DISCOVERY:
-sL: List Scan - simply list targets to scan
-sn: Ping Scan - disable port scan
-Pn: Treat all hosts as online -- skip host discovery
-PS/PA/PU/PY[portlist]: TCP SYN, TCP ACK, UDP or SCTP discovery to given ports
-PE/PP/PM: ICMP echo, timestamp, and netmask request discovery probes
-PO[protocol list]: IP Protocol Ping
-n/-R: Never do DNS resolution/Always resolve [default: sometimes]
--dns-servers <serv1[,serv2],...>: Specify custom DNS servers
--system-dns: Use OS's DNS resolver
--traceroute: Trace hop path to each host

Port Scanning

Quick TCP SYN scanning (-sS: requires root), skipping host discovery (-Pn), of most popular ports:

nmap -sS -Pn 1.2.3.4

Port ranges can be given with -p100-1000 (from :100 to :1000). All ports is -p-. Single port is also accepted: -p 22

UDP Scanning:

nmap -sU -Pn 1.2.3.4

SCAN TECHNIQUES:
 -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans
 -sU: UDP Scan
 -sN/sF/sX: TCP Null, FIN, and Xmas scans
 --scanflags <flags>: Customize TCP scan flags
 -sI <zombie host[:probeport]>: Idle scan
 -sY/sZ: SCTP INIT/COOKIE-ECHO scans
 -sO: IP protocol scan
 -b <FTP relay host>: FTP bounce scan

PORT SPECIFICATION AND SCAN ORDER:
 -p <port ranges>: Only scan specified ports
   Ex: -p22; -p1-65535; -p U:53,111,137,T:21-25,80,139,8080,S:9
 --exclude-ports <port ranges>: Exclude the specified ports from scanning
 -F: Fast mode - Scan fewer ports than the default scan
 -r: Scan ports sequentially - don't randomize
 --top-ports <number>: Scan <number> most common ports
 --port-ratio <ratio>: Scan ports more common than <ratio>

Misc:

• OS discover: -O (uppercase o, not a zero)
• Application discovery: -sV
• Everything: -A (traceroute, app discovery, OS detecetion, port scanning…)

Note the trailing slash in source path: this avoids creating [host:]/destination/path/path.

• -a: archive (i.e. ensures that symlinks, attributes, permissions, owner, etc. are preserved)
• -r: recursive
• -v: verbose (second v gives what files are being skipped and some stats at the end)
• -z: compress
• -h: human-readable format of numbers

• --del | --delete: delete files on the destination that are not sent from the source

• --stats: file-transfer statistics at the end

• -m: prune empty directories from file-list

• -t: preserve modification times

This is how I deploy changes of this site with rsync:

rsync -arvzh --delete public/ vld.bg:www/vld.bg/public_html/ 

Have you ever tried to SSH into an old machine, say a managed switch, UPS or router from the previous decade only to get declined with the following error:

Unable to negotiate with <host>: no matching host key type found.
Their offer: ssh-rsa,ssh-dss

It’s frustrating, isn’t it? OpenSSH implements all of the cryptographic algorithms needed for compatibility with standards-compliant SSH implementations, but since some of the older algorithms have been found to be weak, not all of them are enabled by default. If you want to learn more about it, definitely should read OpenSSH Legacy Options .

But this is a tip, so the short story is that you should use one of offered algorithms by the server, say -oHostKeyAlgorithms=+ssh-rsa. When it comes to ssh-rsa, however that won’t be enough and you would be challenged with another error:

Bad server host key: Invalid key length

The crypto-policy that comes with modern distributions does not allow RSA key sizes < 2048 bit. Some SSH servers are configured with 1024-bit key sizes that can lead to connection failures. -oRequiredRSASize=1024 overrides that default and Voilà.

Example output under different conditions:

touch foo && echo ... > foo

/path/to/watched/dir/ CLOSE_WRITE,CLOSE foo

mv foo bar

/path/to/watched/dir/ MOVED_FROM foo
/path/to/watched/dir/ MOVED_TO bar

rm bar

/path/to/watched/dir/ DELETE bar

Text editors

This is where things get interesting

vim

/path/to/watched/dir/ CLOSE_WRITE,CLOSE foo

Boring, right? However, let’s do :set backup and try again:

/path/to/watched/dir/ CLOSE_WRITE,CLOSE 4913
/path/to/watched/dir/ DELETE 4913
/path/to/watched/dir/ MOVED_FROM foo
/path/to/watched/dir/ CLOSE_WRITE,CLOSE foo

wut?

emacs

/path/to/watched/dir/ CLOSE_WRITE,CLOSE foo
/path/to/watched/dir/ DELETE .#foo

.#foo is never created, yet deleted.

vscode

/path/to/watched/dir/ CLOSE_WRITE,CLOSE asdf
/path/to/watched/dir/ CLOSE_WRITE,CLOSE asdf

Not sure why it does it twice.

Even have it as an alias in my dotfiles :

alias myip='curl -s https://zx2c4.com/ip | head -n1'