[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Re: dbus patch

From: edgar . soldin
Subject: Re: [Duplicity-talk] Re: dbus patch
Date: Fri, 07 Nov 2008 11:35:16 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080914 Thunderbird/ Mnenhy/

Michael Terry wrote:
On Thu, Nov 6, 2008 at 10:44 AM,  <address@hidden> wrote:
the current error & fail concept is convenient, if only the reason for the
error would be delivered more elaboratly (errorcode, stderr).

Note that with my patch, returned error codes do become more
meaningful.  (The code is sent via dbus *and* returned).

Very good. This will help a great deal.

All I wish for is a cleaner error handling and messaging, even if my system
or user can't deliver dbus and glib.

I'm coming around to your view.  Upon reflection, the need for two-way
interaction with duplicity is limited.  So it's mostly duplicity
telling the world something.  If it helps memory usage, code
integration, and integration with ftplicity, I'm fine with a
text-based format.

Something based on the Python logger module (as Ken suggested) that
writes to /tmp/duplicity.USER/PID in a format somewhat like:

WARNING 2 Bad hairdo

ERROR 13 Bad foobar

I can think about it and write up a revised patch.

just a suggestion:
I am looking at working with gpg in '--batch' mode (non interactive for scripts) and found the command line argument '--status-fd' seems to be the planned way to make machine readable information available for software working with gpg behind the scenes.
see file 'DETAILS' in gpg/docs or
chapter: Format of the "--status-fd" output

gpg manpage
      --status-fd n
Write special status strings to the file descriptor n. See the file DETAILS in the documentation for a listing of them.

I could imagine userfriendly errormessages on STDERR plus returned error code (maybe we should make a list for the docs here).Additionally Machine readable messages could go to the '--log-fd' or '--log-file' if a user wants to save them.
As an example a duplicity call could look like:
(/duplicity --log-fd 3 /home/me scp://address@hidden//usr/backup/ 1>/dev/null 2>&1) 3>&1
of course one could also add the output to STDOUT output as well
/duplicity --log-fd 1 /home/me scp://address@hidden//usr/backup/

regards ..ede

reply via email to

[Prev in Thread] Current Thread [Next in Thread]