On Jun 1, 2018 17:09, "Antonio Diaz Diaz" <anto...@gnu.org> wrote:
Hi Paul, Paul Daniels wrote: > I've got a mailfeeder tool that I wrote for testing a long time in > the past, uses standard sockets type stuff in linux in plain C, BSD > licenced and no external libs required. Thank you. I do not plan to implement in ddrescue any mail client code. Using the unix toolbox philosophy I was thinking about someting like make ddrescue execute system( "echo <message> | mailx -s <subject> u...@example.com" ); and just provide the means to specify the email address and a pointer to the configuration documentation of mailx (or whatever email client used). BTW, the mailx command in my machine does not seem able to send emails to the outside world. ST wrote: > PS: such hooks could be used also for other stuff - like backing up the > so far rescued image to an sftp-server (just in case)... Working commands suitable for something like the system call above are welcome. ;-) I think it would be useful to be able to supply generic commands to ddrescue for various trigger conditions. It'd be nice to send a notification on progress, but further processing might also be launched, or backing up as outlined. Also, if ddrescue could launch different commands on different conditions, this could open up for new possibilities, like triggering custom hardware to power cycle a drive, for example. I think it might make sense to pass arguments via environment variables. ddrescue could read some suitable environment variables to determine if the user has specified a script, something like: $ export DDRESCUE_PROGRESS=/path/to/progress_notification_script $ ddrescue /dev/sdb output mapfile Also, ddrescue could in turn pass args to the subprocess via the environment. if (getenv( "DDRESCUE_PROGRESS" )) { char *noargs[] = { NULL }; char *environ[] = { "DDRESCUE_INPUT=/dev/sdb", "DDRESCUE_OUTPUT=output", "DDRESCUE_MAPFILE=mapfile", "DDRESCUE_PROGRESS=progressinfo", NULL}; execve( getenv("DDRESCUE_PROGRESS"), noargs, environ ); } A possible drawback, of course, is that spawned processes can crash and hang, so they should be watched carefully. I'd think the coreutils' timeout commands is fairly good at this. https://github.com/coreutils/coreutils/blob/master/src/timeout.c Regards, Ketil _______________________________________________ Bug-ddrescue mailing list Bug-ddrescue@gnu.org https://lists.gnu.org/mailman/listinfo/bug-ddrescue