I have noticed that rsync --interactive --progress remote: someLocalRemote is aesthetically unpleasant, to say the least. The reason is that stat blocks and interactive prompt blocks have a tendency to step on each other.
This is specially noticeable when you leave rclone running and leave an interactive prompt unanswered for several minutes. Example:
$ rclone sync --progress --interactive remote: localRemote
Enter configuration password:
password:
Transferred: 0 / 0 Byte, -, 0 Byte/s, ETA -
Elapsed time: 8.9srclone: copy "test"?
y) Yes, this is OK (default)
n) No, skip this
s) Skip all copy operations with no more questions
!) Do all copy operations with no more questions
Transferred: 0 / 0 Byte, -, 0 Byte/s, ETA -
Checks: 561 / 561, 100%
Transferred: 0 / 2, 0%
Elapsed time: 55.9s
Transferring:
* test: transferring
* test2: transferring
Please, notice the above stats block overwrites the end of the interactive prompt, which should be:
q) Exit rclone now.
y/n/s/!/q>
So, proposed fix/feature would be to stop printing stat blocks while there is an unanswered prompt on the screen.
Fine. I just wanted to document this behaviour somewhere for reference.
I have not delved into the code yet but I wonder how difficult would it be to actually implement a fix. Github won't accept my email address for creating an account, sadly
You are either an extremely experienced programmer (relative to me) or you lack a basic understanding of the complexities involved in highly concurrent programs like rclone. I get a mild headache just thinking about the test cases needed to verify a change like this:
First, a full fix would involve cancelling/pausing all types of terminal output (from all threads) while an input prompt is open – not just the stats. Next, it requires some sort of global input state protected by a semaphore or channel. This state will then need to be checked (while being careful not to create bottlenecks or deadlocks).
I would be more than happy to help you get a GitHub account for your rclone development, if you find it easy to understand and change the code in the core of rclone.
Most of what I write is glue code these days. Mostly in C and Perl. I am probably closer to the "loser" side of the spectrum than to the "extremely experienced programmer" one.
I got a copy of the code and tried to figure out how the whole thing is organized. I may take a stab at putting together some fix if nobody else wants to, but I make no promises as for production ready code. I don't really do much Go.
From a practical perspective, if nobody steps in with a fix in a reasonable amount of time it would be easier to make "interactive" and non-essential terminal output mutually exclusive. Just an idea.
Your issue is solely related to (a bug in) the implementation of --progress and other terminal output options like -v, -vv, --stats etc. are handled fine. Then the fix will be to include --progress in the same handling as the other similar options. This seems relatively easy.
Your issue is related to (a deficiency in) the implementation of --interactive and similar issues are seen for -v, -vv, --stats etc. Then you need to invent and implement a general solution to a relatively complex problem in rclone. This is the scenario I described in my above post.
I therefore suggest you start by testing/debugging how --interactive works together with the other output options/flags.
