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

From: Michael Witten <mfwitten@mit.edu>
Date: Feb 3, 2008, 20:59 UTC
Message-ID: <5C100A3B-0B4A-4D4E-B68B-1A54674A795A@mit.edu>
In-Reply-To: <87CDEC9F-8153-48D0-AD1C-A3B3CEF6FDAE@MIT.EDU>

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

Show 8 quoted lines

>> * "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.

Show 15 quoted lines

>> * 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