(02/23/2011 08:59 AM), Giuseppe Scrivano wrote: > Micah Cowan <[email protected]> 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/
