Progress bar on non-interactive runs

[Ekleog]

When running in a systemd service, rustic gives zero indication of progress. For long backups (eg. hours-long), this can be pretty destabilizing.

Suggested change:

This command currently displays nothing until the backup completes:

$ rustic backup /home --json --progress-interval 1s &| cat

Instead, setting progress-interval would have rustic output one line per second, with a quick summary of what otherwise would be written in the progress bar. It might also make sense to have a non-interactive progress-interval defaulting to like 10 seconds.

What do you think about it?

Anyway, I'm in the process of migrating from borgmatic to rustic after borgmatic started freezing on me with week-long backups, and it looks much more usable than borgmatic for now, and easier to understand. So thank you for all the work you're putting in here!

[aawsome]

Thanks for the proposal @Ekleog!

I think this could be most easily added by adding a new feature (independent from the progress bar) which just prints a status every x seconds.

If anyone wants to start a PR, I can give more detailed directions...

[fweisenhorn]

Hello!

I've had a look at how the progress bar is currently implemented, to check if a modified progress bar could be used to print status updates. However, the indicatif progress bars will only be drawn to user attended terminals, “so that piping to a file will not produce useless escape codes in that file” (fair enough).

indicatif uses a custom struct 'Ticker' for the regular redrawing, although it is pub(crate). I guess I could copy the code and use it to regularly print the status, although I'd love to hear what you had in mind.

Another remark: I was a bit surprised that rustic gives progress information to stderr when running in a terminal, but not when piping the output to a file. Is this documented? I couldn't find it, anyway.
My suggestion would be (I volunteer to implement it), if rustic detects a terminal, it draws the pretty progress bars, and if not, it simply prints regular status updates to stderr or stdout, with the two progress options that already exist.

[ikhyunAn]

Can I get more detailed directions if this issue is still open? @aawsome
I'm a newcomer here btw, looking for ways to start contributing!

[aawsome]

Hi @fweisenhorn and @ikhyunAn
Good to hear that you plan to work on this!
I think the idea @fweisenhorn is something to start with. I also think we need a way to not "overflood" the output with logging information. That means we need some way to dertermine if we want to print an update instead of printing everytime the progress is updated (which can be very often!). But this can be as easy as storing a timestamp of the last output and only output if the time intervall is over.

About the implementation, it's all in progress_options.rs - this is where changes IMO need to go.

I think it is better to have some code in a PR and then (maybe) discuss the details!