I may actually incorporate that into the system() call in the module itself now that I think about it. The Hello World implementation was just a quick way for me to debug while I developed it and it's probably smarter to dump it to /dev/null by default.

Seems like this should be baked in to the module. There don't seem to be any circumstances where you would want stdout/stderr from duress.d scripts to appear.

You have the freedom to do whatever you want with the script. It's trivial to `exec >/dev/null 2>/dev/null` first thing in a script if you want it to be silent.

Do you want to first find that out when you're under duress? Sensible defaults matter.

Are you seriously writing a script when the cops are at your door? No, you aren't. You always need to verify that your protective mechanisms work before actually relying on them.

As I alluded to in my original comment, you might not pick up on a transient error like an I/O error during testing. This is exactly the sort of thing a sensible default setting in the program should cover.

I'm sorry but error handling and testing requirements are true for any software or script a person writes. The application should not give a shit, and a simple execve() is the best way to go about it. It's the principle of least surprise, and people have had to keep in mind fork/exec semantics for decades.