Note that if you output status along the lines of the logfile that I
suggested to a pipe, a separate executable could provide status.

It's pretty easy to imagine an executable that would use the STATUS to
select a window, the URI to add/update a line in that window, and basic
stats (size, amount transferred, time started) to illustrate progress.

This would decouple the status interface from curl proper, and you could
even select which executable at runtime.

So you could have a (n)curses implementation, a text with interrupt
character implementation, or just log the status for some other processing.

And with tee - you could do both.

For this, all curl proper would have to do is:

  * Create a pipe
  * fork/exec a status subprocess (choose which one from a switch. e.g.
    --status-cmd="curl-curses-status" or --status-cmd="tee -a logfile |
    curl-tty-status")
  * write status updates to a pipe
  * close the pipe at end of processing
  * wait for the subprocess to exit

The sub-process need only read its stdin and update the screen, tty, or
log.  So it does a select() on /dev/tty commands & the pipe.

If --status-cmd has a pipe character, you exec "/bin/sh -c ...",
otherwise the named program.

You could have some aliases for users - --progress=window,
--progress=console - but the mechanism would be the same.

Best of all, this means that presenting status can be a separate
project.  So the several options could be done in, er, parallel.  And
curl itself doesn't need to get much bigger.

Anyhow, this is a rough outline - I'm sure there are some details (like
exactly what's in the update messages) to work out.  But the
architecture seems sound.

FWIW.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html