> @Ander Would you like to contact upstream ? (We are not in hurry.)

Yep, I guess I could do that. Ask me for feedback if I haven't reported anything on this for a while.

> What's wrong with pushing/discussing them upstream?

Absolutely nothing; I think that's entirely appropriate. I don't really have a vested interest in it any longer, though, so it'd probably be better for someone else to get the ball rolling with them.

> I'm looking at the latest getpass sources and they haven't changed much.

That's part of why I was wondering if they might be opposed to the changes, simply on the grounds of behavior stability. But even if that's the case, they probably wouldn't be opposed to a "gnu_getpass2", or perhaps "set_gnupass_opts", to work around such an issue.

This bug was opened back when I was a maintainer, which I'm not now, nor am I actually involved in wget development in any way these days, so perhaps this should be reconsidered by current the maintainer.

But yes, improving gnu_getpass would definitely be preferable. I guess I was assuming that gnu_getpass had been around long enough that changing its behavior meaningfully would be undesirable to many (much like wget itself: sometimes "fixing" poor behavior leads to more problems than it solves, when people have gotten used to dependability, and requires a new, alternative interface). But even so, I imagine it'd be preferable to put the new interface into gnulib.

It's conceivable, these seven years later, that most of these improvements have already been made to gnu_getpass or another alternative interface, so that would bear investigation.

In any case, these were admittedly small annoyances, and wget's certainly been doing fine using gnu_getpass in the meantime, which is why the bug is low pri. If someone decides it's not worth the hassle of maintaining our own separate solution, I'd be fine with this bug being closed.

gnu_getpass has some shortcomings.

• It ignores SIGINT, whereas I'd want it to exit out.
• It treats EOF and an empty line as the same, whereas I'd wish to treat the former as an exit condition, and the latter as an empty password.
• When it gets EOF, it doesn't append an extra newline, allowing the prompt to appear immediately after the prompt, rather than on a line on its own. This is difficult to address, because it's difficult to determine where getpass's output went (freshly opened /dev/tty, or stderr?).