On 3 Feb 2008, at 12:59 PM, Michael Witten wrote:
* "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.
* 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
