crypt.awk is not finished nor documented.

[hipcatkiss]

crypt.awk is old, WIP, no documentation at all. awk is a weird choice anyway. If a bash solution is appropriate (you said you try to avoid it), I can come up with a pull request, documentation and all. Documentation is asciidoc, if that's a problem.

[xplshn]

Why bash? sh shall be used for portability's sake, you can call awk from within sh if you need something more powerful.

[classabbyamp]

awk is a great choice for parsing a line-based text format

[hipcatkiss]

@xplshn

Why bash?

bash because it itself is miserable enough to program.

portability

This repository is called "runit init scripts for Void", which portability, exactly, do you mean?

awk

My script doesn't need awk. Only lsblk and a bit of coreutils (head IIRC).

@classabbyamp

awk is less known and I did not find it convenient enough for this specific purpose.

[ahesford]

Awk is well suited to this task. That a newer generation of Unix users find it obscure is unfortunate, but does not mean that this is a weird choice. Being "old" is not, ipso facto, a valid criticism or justification for replacement.

Bash is definitely not a suitable replacement here. Not all Void installations built on encrypted filesystems will even have bash installed, but all should have an awk implementation. Using POSIX shell would avoid this issue, but a lot of the core parsing task becomes much more cumbersome in shell.

I see no good argument for scrapping the existing crypttab processor in favor of a shell alternative. The best option would be to identify the specific deficiencies of the current parser and rectify them.