Oswald,
On 2018-10-01 10:02, Oswald Buddenhagen wrote:
On Sun, Sep 30, 2018 at 09:13:39PM +0200, Kristian Larsson wrote:
So you're aiming for the PostCmd?
i think so ...
Ok, great :) I think that sounds great and I want to emphasize how I
don't think it needs to be an either or solution. Implementing better
options for exits codes / stdout can be useful even when PostCmd exists.
The other suggestions include writing files in various places and
checking what's been updated. They are even worse monumental hacks
than what I wrote.
no, because these are clean interfaces, even if the data path is
somewhat convoluted.
Are they meant to be used that way or are they simply hacky ways of
using side effects of the current behaviour of the program? Do you
commit to supporting those cases and not changing as to cause backwards
incompatibility?
Nevertheless, I think it's way too convoluted for something that really
shouldn't be that hard...
you otoh are parsing output that was never meant to
be machine-readable.
btw, if you want to hack it without patching mbsync, use 'script' or
'unbuffer'.
Okay, sorry, I wasn't clear. I wanted to differentiate between my patch,
which deserves your description, and the principle of using stdout or
exit codes as a method of conveying information. I think the latter
should be supported but perhaps a cleaner patch than mine should be
applied to achieve it :)
nmap has -oG for greppable output. Can we have something similar? If we
clean up a patch that just writes the final state in a machine parseable
format? Could be key=value style or something else.
i'll think some more about yuri's approach. i still don't like it, but
it isn't worse than the lumped exit code that is already in place.
That would work for me too. I wonder though, and I think it was you who
wrote this in a thread, I would like to differentiate between whether
the master or slave was updated and only trigger other programs based on
one. Do you see that going into the exit status? Or do we loose some
granularity?
Thanks!
Kind regards,
Kristian.
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
