PATCH: better progress reporting
cs at zip.com.au
Fri Mar 15 11:54:34 EST 2002
On 11:35 15 Mar 2002, Martin Pool <mbp at samba.org> wrote:
| On 14 Mar 2002, Cameron Simpson <cs at zip.com.au> wrote:
| > timeconfig-3.2.5-1.i386.rpm
| > 158253 100% 160.48kB/s 0:00:00
| > timidity++-2.10.4-2.i386.rpm
| > 9309389 100% 397.71kB/s 0:00:22
| > tix-8.2.0b1-67.i386.rpm
| > 456809 100% 437.78kB/s 0:00:01
| > tk-8.3.3-67.i386.rpm
| > 1371196 100% 433.77kB/s 0:00:03
| Good in concept. The current output does look a bit dumb.
| I'd like to take a broader look at our progress reporting.
Cool. But perhaps put this in anyway until you've done something more
thorough? I don't really want to keep personal patches floating around
| Since we
| have the whole file list, in theory we know not only about progress
| through the current file, but also progress in the overall tree.
| Perhaps something like the output from Debian's apt, if you know that.
| I'm wondering about a --machine-readable option that produces status
| output in a way that can be easily parsed by scripts or GUIs and that
| allows room for extension without breaking existing scripts. At the
| moment I'm leaning toward an rfc822-like plain text format with tags
| at the start of each line, and encouragement to parsers to ignore
| lines they do not understand.
Sounds nice. I'd like to see all the -v stuff go there too.
Coarse examples of -v tracing:
LOCALSTAT pathname results
REMOTESTAT pathname results
# well, this would mean "the far end just sent us stat info"
DECIDE what will happen to pathname
CREATE pathname stat-info?
REPLACE pathname (old vs new?)
PROGRESS pathname progress-info...
[Reads a few lines down.] Or of course "Localstat:" ...
| File-Begin: timeconfig-3.2.5-1.i386.rpm
| File-Size: 158253
| Progress: 4000
| Progress: 8000
| File-Complete: timeconfig-3.2.5-1.i386.rpm
This kind of presumes that thens a start-end sequence with no interleaving.
How about rfc822-like multilines:
i.e. an indented line continues the previous. That gets us records, which
more sanely supports interleaved activity. The obvious downside that you
can detect end of record without seeing the beginning of the next record,
which sucks for progress reporting. This applies to your proposal too.
I guess this would push me back you my first syntax above, with long
lines for lots of info if needed.
| I guess somebody is going to say "XML" at this point, but it does seem
| more complex.
And very shell hostile. XML is easily the wrong thing here unless we get into
complex data structures.
On the subject of shell hostility, rfc822 is a bit shell hostile.
This is why my first instinct is to go for the plainer keyword syntax
I offered above:
Cameron Simpson, DoD#743 cs at zip.com.au http://www.zip.com.au/~cs/
...don't permit your spirit to be dampened by pinheaded bottom liners who
feel the proper work environment is one that resembles a benign prison camp.
- a Good Times horoscope
More information about the rsync