Re: [Bug-wget] Use stderr instead of stdout for --ask-password

[Micah Cowan]

(02/23/2011 08:59 AM), Giuseppe Scrivano wrote:
> Micah Cowan <address@hidden> writes:
> 
>> On 02/23/2011 01:23 AM, Giuseppe Scrivano wrote:
>>> Hello Gilles,
>>>
>>> thanks for your patch.  I am not sure it is a good idea to use stderr
>>> to prompt a message to the user.  I would just inhibit the message when
>>> -O- is used.
>>
>> Personally, I agree with Gilles; in every single instance other than
>> here, we always write information meant for the user to stderr (I
>> believe for the reason he cites: so as not to interfere with the output
>> in the case of -O-). I'd say we should either blindly write to stderr in
>> all cases, or else consider specifically finding the terminal and
>> writing to that (ttyname?)
> 
> hm.. in functions like print_usage (main.c), I see we differentiate
> between an error message and an usage string.

We do print_usage improperly anyway, since we still issue it to stdout,
even when printing usage results from a usage error. Correct behavior
would be to only print it to stdout in response to --help, and always
print it (or perhaps just a simple error) to stderr otherwise.

In the case of --help, it _is_ the program output, so printing it to
stdout is appropriate.

> When the user specifies
> --ask-password then the password prompt is a desired behaviour rather
> than an error.
> 
> In what cases do we use stderr for something different than an error
> message?

Literally everywhere, other than outputting downloaded content (and as
you point out, --help). Progress bars. Informational messages.
Connection status. You name it. Everything goes to stderr.

Note that stderr is not "just for errors". The C standard describes
stdout as being "for conventional output", and stderr "for diagnostic
output". It is very frequently used in Unix for informational "out of
band" messages (i.e., any output that shouldn't be included in output
that might be redirected to another program as input).

This situation is neither, of course, but I feel it absolutely shouldn't
go into the "conventional output" (it's closer to "diagnostic" output
anyhow, since it's intended specifically for the user, rather than
whatever might be consuming "program output"). I also think that
suppressing it when the user does a rather straight-forward
"wget --ask-password -O- foo.com | <some command>" is the wrong
behavior, since it'll just silently block there. You could perhaps
decide to disable its use with -O- altogether, but that significantly
reduces its utility IMO.

Ideally proper behavior would be to find the tty and use that (since,
after all, it is an interactive prompt), either by checking all of fds
0, 1, 2 for "tty-hood", or using ttyname(), but this has the
disadvantage of not working for Windows (AFAIK - certainly the
implementation would differ). It does have the advantage of correctly
handling the case when either or both stdout _and_ stderr could be
redirected (for stderr, of course, we offer -o log, which wouldn't
impact the prompt, but still, ideally redirecting stderr instead of
using -o log wouldn't impact the prompt either - but it's better than
letting stdout redirections affect it).

Compare other programs that issue prompts (ignoring ones whose normal
use cases are interactive, such as gdb or passwd). Ssh makes a good
example: it always writes the prompt to (and, actually, reads the
password from) the terminal, rather than stdin. You could make a case
that wget should also only read the password directly from the terminal,
so that we could still use -i in combination with it (or, I forget,
maybe getpass() does that already anyhow). We don't have the problem
with wget that one sometimes has with ssh, where occasionally a user
wants to pipe (from "echo"?) the password into ssh's prompt (which
doesn't work), since wget already supports other means for specifying
the prompt directly on the command line. But of course, all of this is
fairly Unix-specific.

Changing the prompt to stderr seems like a simple, single step forward
towards "proper" usage. It's not perfect, but it strikes me as a good
sight better than using stdout, which really ought to be reserved for
"program results"-type output, IMO.

-- 
Micah J. Cowan
http://micah.cowan.name/