On Sat, 16 Mar 2002, lsi wrote:

Thanks for explaining, my comments follow...

> What I wanted to do was see the progress indicator onscreen, and have any
> errors recorded in a file.
>
> If there was a switch to send progress indicator output to stdout (only
> works if -O also used), then all would be fine and dandy.

Well, in theory there's nothing that prevents us from sending the progress
meter to a stream of its own, and have it use stderr by default unless told
otherwise.

> curl -O ftp://ftp.netscape.com/cc32d479.exe --stderr myfile.txt
>
> will currently produce a large myfile.txt (containing lots of progress
> indicator data), which *may* contain an error at the end of the file (slow
> to search). Also, no onscreen output will be visible, despite the transfer
> potentially taking a long time.
>
> Adding a switch to send the progress indicator to stdout will mean
> myfile.txt is only created if there is an error, and any errors will be at
> the top of the file - and it will mean a progress indicator is visible
> onscreen, should no error occur. This makes more sense to me!
>
> Please don't ask why I can't detect curl's exit codes. :)

This would require us to keep a separate stream for the (libcurl built-in)
progress meter and add an option to set it to whatever.

Today, it is using the stream for 'stderr' and we have an option to
set/redirect 'stderr' to whereever we please.

Of course I (we) never expected people to use the stderr redirect feature to
figure out if an error occurred or not like this, as it seems so much better
to do it by reading the exit code... :-)

To summarize: I would approve of patches that offer this functionality, but I
don't think I'll be able to add this myself within the nearest future. I'll
make a note about in the TODO file so that it won't get forgotten.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/