On Thu, Feb 23, 2017 at 03:10:28PM +0100, Yuri D'Elia wrote: > On Thu, Feb 23 2017, Oswald Buddenhagen wrote: > > On Sat, Feb 18, 2017 at 10:39:14AM +0100, Yuri D'Elia wrote: > >> As for the second patch, I'd like to contribute extended exit status > >> codes. To avoid breaking old scripts, I'd add a new switch > >> (-e/--exit-code or something like it) that changes the meaning of the > >> exit status. > >> > > well, i'm still not such a big fan of this, and would really prefer a > > callback mechanism. this would be also more compatible with a future > > daemon mode, where exit codes are fairly meaningless. would you be > > willing to work on that? > > I see the use case when running as a daemon. > > You still need to specify the indexing status to the child process > though. Would the same scheme be fine? > i'm not sure i understand the question ...
i'd spawn one notifier per successful run on a single box. the command line would be configurable, with possible parameters being abstract mailbox name and actual path (if supported by the driver). additionally, the notifier's stdin would be configurable, with uid, filepath (if supported), applied actions, and possibly headers being possible parameters, one line per message (and nothing if not configured). alternatively, one could just dump json to a file (which may be a fifo). > I'd avoid having too many handlers there. Coming from offlineimap, just > having an exit code is much simpler to script. > well, in the easiest case, you can configure "touch ~/.mailbox-changed" as your notifier. dealing with that is arguably _easier_ than with a bit-field exit code: test -f. the json approach would be similarly trivial to handle: test -s. the one downside is that in either case you need to actually configure something instead of just passing an additional option, but that seems trivial enough. one thing to consider: you're really just interested in changes on the slave, so it probably makes sense to realize the whole thing asymmetrically. this is equally true for your approach. > > it's for the autotests, as you could have found from the history > > (ab11737b3). ;) > > I saw the commit, but I don't see how gdb is used? > it's just attached to the crashed process, so you can use it interactively. when you're done, you exit, which is when the crashed process also exits. i'll note that this isn't bullet-proof, as the used functions aren't signal-safe. still, it has proven useful. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
