BTW to improve the reliability of that test I believe you would need a sleep (smaller, e.g. of 0.1) between the Thread.new and assert M.works?, otherwise it's likely the M.works? runs first and then the other thread will see the constant is autoloading and wait, and anyway that thread does not check what is defined on M. For the test to fail it needs to be the Thread.new running first and defining the constant but not yet the method, before the main thread keeps running and call the method.

The expect wait command returns more arguments if the spawned process is killed but unbuffer just always returns the 3rd argument.

In any case signal handling in shells is one of the least reliable and portable aspects. You'll find behaviours vary greatly between shells and often between different versions of a same shell. Be prepared for some serious hair pulling and head scratching if you're going to try to do anything non-trivial.

Also, this code will fail if $$ is not the process group leader, such as when the script is run under strace. Since a call to setsid(2) is probably tricky from a shell script, one approach might be to ps and obtain the process group ID from that.

you really need #!/bin/sh -m for correct behavior of nested subshells. fg, bg, and wait wont work correctly otherwise