> > [...] Does that make sense?
> not really. ^^

I see, well in the mean time i have been able to construct my use-case by
(ab)using environment variables, hopefully this makes it clearer. In a wrapper
shell script i have

#!/bin/sh
export SOME_ENV_VARIABLE=$(obtain password)
while true; do
        mbsync --stuff
        sleep period
done

and in .mbsyncrc i have PassCmd "echo $SOME_ENV_VARIABLE". This is almost
exactly what i want, but of course i would prefer to have this all in the
binary itself.

Thanks for the below hints, i'll take have a go at implementing this. I'm
afraid i can't promise much---i'm an amateur with no formal training, but
hopefully with some study the code will give up its secrets :)

> you basically want to en-loop the last "paragraph" of main() (including the
> line before it). you may need to re-initialize some other members of mvars
> as well, and possibly even avoid that some structures get freed during the
> run - i don't remember the details (valgrind will tell you, heh).
> 
> where it gets hairy is error handling, because it becomes really important
> to differentiate between permanent and transient errors, and the category of
> "permanent but acceptable" errors ("serious warnings" from an operational
> perspective) exists as well. i've pondered this here in the context of exit
> codes, in particular relating to a patch from yuri.
> 
> > Is there interest in such a simplistic feature upstream?
> > 
> in principle yes; it adds sufficient value on its own.
> my concern is to keep things reasonably clean in case a more sophisticated
> trigger mechanism is added, but i don't see much room for problems here.
> 
> the default output level should print something like "Sleeping %d seconds
> before next round; use ctrl-C to exit.\n" after each round.
> remember to clear the stat counters.
> --periodic is a good option name, and the corresponding -p is free as well.
> 
> base off the wip/master-next branch to avoid conflicts (the pre-existing
> functionality should be still safe to use).


_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel

Reply via email to