Micah Cowan wrote: > 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). Windows supports isatty(3). Anyway, finding the prompt at the redirected error file isn't something that would break the user expectations too much .
> 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). Seems it does. According to its man page: > The getpass() function opens /dev/tty prompt, turns off echoing, > reads one line (the "password"), restores the terminal state and > closes /dev/tty > 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. AFAIK ssh did it on purpose, for security purposes. > 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. I agree. Simple and quite good.
