[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ángel González
Subject: Re: [Bug-wget] Use stderr instead of stdout for --ask-password
Date: Thu, 24 Feb 2011 18:47:08 +0100
User-agent: Thunderbird

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]