Re: [PATCH 1/2][Perlers?] git-send-email: ssh/login style password requests

On 3 Feb 2008, at 12:59 PM, Michael Witten wrote:

quoted

* "Password:" prompt still echoed password "abc".  There was no
 extra newline before "You said <junio><abc>".

Indeed. I tested your code and my git-send-email code with all three
backend implementations (Term::ReadLine::Stub, Term::ReadLine::Gnu,  
and
Term::ReadLine::Perl). The problem with echoing seems to be a fault of
the Term::ReadLine::Perl implementation.

Yiarg!

It would appear that Term::ReadLine::Gnu's implementation (of at least
readline) delays signal handling, so that ^c (C-d) doesn't do anything  
while
the prompt is up; I suppose this is an artifact of of this:

	http://perldoc.perl.org/perlipc.html#Deferred-Signals-(Safe-Signals)

For instance:

	What subject should the initial email start with?<^c><ENTER>

Only after <ENTER> is the handler invoked.

quoted

* In either case, typing <Enter> returns an empty string from
 $term->readline() so the "while (!defined)" loop does not buy
 us anything.

Frankly, I wrote that readline code according to the other uses of  
readline,
as I am not well versed in these things.

Because all other uses of readline are wrapped in such while loops,  
I assume
that they are meant to cover systems with non-blocking (unbuffered)  
IO, rather
than to continue to prompt the user due to empty strings.

Should empty-string passwords not be allowed?

Perhaps these loops are meant to handle ^d (C-d; VEOF). This is  
because issuing
EOF causes input operators/functions to return undefined; in fact,  
using just the
'crypt' method, ^d is unhandled, causing a runtime error. Is there a  
way to setup
a signal handler for this control character rather than using checks?

Michael Witten