duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] [ftplicity:feature-requests] #45 Feature: Parseable


From: edgar . soldin
Subject: Re: [Duplicity-talk] [ftplicity:feature-requests] #45 Feature: Parseable output, especially dates
Date: Sat, 19 Jan 2019 21:56:39 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 1/19/2019 9:27 PM, Marc Diethelm wrote:
> Thanks for the quick reply ede! I didn't have these duplicity options on my 
> radar.

no problem

>Tried them and now I'm confused. Their output is supposed to be easily 
>consumed by other programs it says. Yet the whole thing is still looks very 
>much made for humans.. Some lines are prefixed with a dot which I suppose 
>could help parse out the relevant info. But for |list| I'm seeing this:
>
> NOTICE 1
> . Local and Remote metadata are synchronized, no sync needed.
SNIP
> . No orphaned or incomplete backup sets found.
>
> I'm obviously most interested in the "Full"/"Incremental" lines. But the rest 
> of the info is very valuable too. But I can't see how this can be parsed 
> without lots of regexes and or grepping and compiling and converting data. 
> There are no concise identifiers and delimiters to easily find certain lines 
> and data of interest. And here too the date is in human-readable format.
>
> As I said I'm confused. To offer a quick and incomplete example, here's an 
> idea of what I would expect to see:
>
> last_full::20190119T194604Z
> volumes::2
> list:
> time::volumes::type
> .20190119T194604Z::1::full
> .20190119T194604Z::1::incremental
>
> I'm looking forward to hearing your thoughts. Thanks.

would you mind joining the duplicity mailing list?
  https://lists.nongnu.org/mailman/listinfo/duplicity-talk
i think it might a better place to discuss this duplicity feature.

it was implemented years ago to allow machine readable output. i insisted at 
that time to have it optional and pipeable to a specific fd as i was planning 
to parse it in the future with duply. never came around to it though.
we can probably improve it with your input or even python patches.

..ede/duply.net



reply via email to

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