3 ms·
Just do this in your script rm -rf /secret/files > /dev/null 2>&1 That pipes STDOUT to /dev/null and redirects STDERR to STDOUT.
by dheera 5y ago
Just do this in your script
rm -rf /secret/files > /dev/null 2>&1
That pipes STDOUT to /dev/null and redirects STDERR to STDOUT.
- sleavey 5y agoSeems 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.
- wowaname 5y agoYou 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.
- sleavey 5y agoDo you want to first find that out when you're under duress? Sensible defaults matter.
- wowaname 5y agoAre 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.
- sleavey 5y agoAs 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.
- wowaname 5y agoI'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.
- nuvious 5y agoI 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.