Re: [PATCH] git-send-email: ssh/login style password requests

Michael Witten [off-list ref] writes:

In any case, I'm looking for your endorsement of a signal handler
as the means to solve the main problem.

Heh, unfortunately I am not "the resident Perl expert on the
list", so I would be waiting for suggestions from them.

A single signal handler is used for both SIGTERM
and SIGINT in order to clean up after an uncouth
termination of git-send-email.

In particular, the handler resets the text color
(this cleanup was already present), turns on tty
echoing (in case termination occurrs during a
masked Password prompt), and informs the user of
of any temporary files created by --compose.

Signed-off-by: Michael Witten <redacted>
---

	Perlers, please comment.

 git-send-email.perl |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index ed0a473..a0c9e8f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl

@@ -24,8 +24,6 @@ use Data::Dumper;
 use Term::ANSIColor;
 use Git;
 
-$SIG{INT} = sub { print color("reset"), "\n"; exit };
-
 package FakeTerm;
 sub new {
 	my ($class, $reason) = @_;

@@ -201,6 +199,29 @@ my %config_settings = (
     "aliasesfile" => \@alias_files,
 );
 
+# Handle Uncouth Termination
+sub signal_handler{
+	
+	# Make text normal
+	print color("reset"), "\n";
+
+	# SMTP password masked
+	system "stty echo";
+
+	# tmp files from --compose
+	if (-e $compose_filename) {
+		print "'$compose_filename' contains an intermediate version of the email you were composing.\n";
+	}
+	if (-e ($compose_filename . ".final")) {
+		print "'$compose_filename.final' contains the composed email.\n"
+	}
+
+	exit;
+};
+
+$SIG{TERM} = \&signal_handler;
+$SIG{INT}  = \&signal_handler;
+
 # Begin by accumulating all the variables (defined above), that we will end up
 # needing, first, from the command line:
 

-- 
1.5.4.rc5.17.g8ca921-dirty

Whilst convenient, it is most unwise to record passwords
in any place but one's brain. Moreover, it is especially
foolish to store them in configuration files, even with
access permissions set accordingly.

git-send-email has been amended, so that if it detects
an smtp username without a password, it promptly prompts
for the password and masks the input for privacy.

Furthermore, the argument to --smtp-pass has been rendered
optional.

The documentation has been updated to reflect these changes.

Signed-off-by: Michael Witten <redacted>
---

	Perlers, please comment.
	
	Because AsciiDoc is a nuisance, the modifications
	below are somewhat difficult to discern. Please
	take look here:
	
		http://web.mit.edu/mfwitten/git-send-email.html
	
	Also, I have quoted the man page text below:
	

--smtp-user
   Username for SMTP-AUTH. In place of this option, the following
   configuration variables can be specified:

   o  sendemail.smtpuser

   o  sendemail.<identity>.smtpuser (see sendemail.identity).

   However, --smtp-user always overrides these variables.

   If a username is not specified (with --smtp-user or a configuration
   variable), then authentication is not attempted.

--smtp-pass
   Password for SMTP-AUTH. The argument is optional: If no argument is
   specified, then the empty string is used as the password.

   In place of this option, the following configuration variables can
   be specified:

   o  sendemail.smtppass

   o  sendemail.<identity>.smtppass (see sendemail.identity).

   However, --smtp-pass always overrides these variables.

   Furthermore, passwords need not be specified in configuration files
   or on the command line. If a username has been specified (with
   --smtp-user or a configuration variable), but no password has been
   specified (with --smtp-pass or a configuration variable), then the
   user is prompted for a password while the input is masked for
   privacy.

 Documentation/git-send-email.txt |   39 +++++++++++++++++++++++++++++++++----
 git-send-email.perl              |   23 ++++++++++++++++++---
 2 files changed, 53 insertions(+), 9 deletions(-)

diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0554f2b..4f4caa4 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt

@@ -96,11 +96,40 @@ The --cc option must be repeated for each user you want on the cc list.
 	servers typically listen to smtp port 25 and ssmtp port
 	465).
 
---smtp-user, --smtp-pass::
-	Username and password for SMTP-AUTH. Defaults are the values of
-	the configuration values 'sendemail.smtpuser' and
-	'sendemail.smtppass', but see also 'sendemail.identity'.
-	If not set, authentication is not attempted.
+--smtp-user::
+	Username for SMTP-AUTH. In place of this option, the following
+	configuration variables can be specified:
++
+--
+		* sendemail.smtpuser
+		* sendemail.<identity>.smtpuser (see sendemail.identity).
+--
++
+However, --smtp-user always overrides these variables.
++
+If a username is not specified (with --smtp-user or a
+configuration variable), then authentication is not attempted.
+
+--smtp-pass::
+	Password for SMTP-AUTH. The argument is optional: If no
+	argument is specified, then the empty string is used as
+	the password.
++
+In place of this option, the following configuration variables
+can be specified:
++
+--
+		* sendemail.smtppass
+		* sendemail.<identity>.smtppass (see sendemail.identity).
+--
++
+However, --smtp-pass always overrides these variables.
++
+Furthermore, passwords need not be specified in configuration files
+or on the command line. If a username has been specified (with
+--smtp-user or a configuration variable), but no password has been
+specified (with --smtp-pass or a configuration variable), then the
+user is prompted for a password while the input is masked for privacy.
 
 --smtp-ssl::
 	If set, connects to the SMTP server using SSL.

diff --git a/git-send-email.perl b/git-send-email.perl
index a1a9d14..ed0a473 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl

@@ -157,7 +157,7 @@ my $compose_filename = ".msg.$$";
 
 # Variables we fill in automatically, or via prompting:
 my (@to,@cc,@initial_cc,@bcclist,@xh,
-	$initial_reply_to,$initial_subject,@files,$author,$sender,$compose,$time);
+	$initial_reply_to,$initial_subject,@files,$author,$sender,$smtp_authpass,$compose,$time);
 
 my $envelope_sender;
 

@@ -177,7 +177,7 @@ my ($quiet, $dry_run) = (0, 0);
 
 # Variables with corresponding config settings
 my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
-my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_authpass, $smtp_ssl);
+my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_ssl);
 my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
 my ($no_validate);
 

@@ -214,7 +214,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
 		    "smtp-server=s" => \$smtp_server,
 		    "smtp-server-port=s" => \$smtp_server_port,
 		    "smtp-user=s" => \$smtp_authuser,
-		    "smtp-pass=s" => \$smtp_authpass,
+		    "smtp-pass:s" => \$smtp_authpass,
 		    "smtp-ssl!" => \$smtp_ssl,
 		    "identity=s" => \$identity,
 		    "compose" => \$compose,

@@ -647,9 +647,24 @@ X-Mailer: git-send-email $gitversion
 			die "Unable to initialize SMTP properly.  Is there something wrong with your config?";
 		}
 
-		if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
+		if (defined $smtp_authuser) {
+
+			if (!defined $smtp_authpass) {
+				
+				system "stty -echo";
+
+				do {
+					$_ = $term->readline("Password: ");
+				} while (!defined $_);
+
+				system "stty echo";
+
+				$smtp_authpass = $_ if ($_);
+			}
+
 			$auth ||= $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
 		}
+
 		$smtp->mail( $raw_from ) or die $smtp->message;
 		$smtp->to( @recipients ) or die $smtp->message;
 		$smtp->data or die $smtp->message;

-- 
1.5.4.rc5.17.g8ca921-dirty

Michael Witten [off-list ref] writes:

 2 files changed, 53 insertions(+), 9 deletions(-)

Documentation part looks very clear.  Thanks.

+		if (defined $smtp_authuser) {
+
+			if (!defined $smtp_authpass) {
+				
+				system "stty -echo";
+
+				do {
+					$_ = $term->readline("Password: ");
+				} while (!defined $_);
+
+				system "stty echo";
+
+				$smtp_authpass = $_ if ($_);
+			}
+

Another example which appears in PerlFAQ #8 uses ReadKey with
its ReadLine, like this:

    use Term::ReadKey;
    ReadMode('noecho');
    $password = ReadLine(0);

which is different from Term::ReadLine's "ReadLine".  An earlier
example you cited from perlfunc.pod's crypt() entry does:

    system "stty -echo";
    print "Password: ";
    chomp($word = <STDIN>);
    print "\n";
    system "stty echo";

In either case, I was worried about the interaction between the
Term::ReadLine backend implementation and "stty".

Actually, I just tried this myself:

    #!/usr/bin/perl -w

    use Term::ReadLine;
    my $term = new Term::ReadLine 'foobar';

    my ($user, $password);
    while (!defined $user) {
            $user = $term->readline("User: ");
    }
    system 'stty -echo';
    while (!defined $password) {
            $password = $term->readline("Password: ");
    }
    system 'stty echo';
    print "You said <$user><$password>\n";
    print "ReadLine backend used was ", $term->ReadLine, "\n";

In my case, the backend was "Term::ReadLine::Perl".  A few
problems:

 * After typing "junio <Enter>" to "User:", an extra newline is
   left before "Password:" prompt;

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

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


 

Michael Witten [off-list ref] writes:

+# Handle Uncouth Termination
+sub signal_handler{
+	
+	# Make text normal
+	print color("reset"), "\n";
+
+	# SMTP password masked
+	system "stty echo";
+
+	# tmp files from --compose
+	if (-e $compose_filename) {
+		print "'$compose_filename' contains an intermediate version of the email you were composing.\n";
+	}
+	if (-e ($compose_filename . ".final")) {
+		print "'$compose_filename.final' contains the composed email.\n"
+	}
+
+	exit;
+};
+
+$SIG{TERM} = \&signal_handler;
+$SIG{INT}  = \&signal_handler;
+
 # Begin by accumulating all the variables (defined above), that we will end up
 # needing, first, from the command line:

Now I think this patch (except the part about "stty echo") makes
sense, although I did not try killing a send-email session with
signals myself.

Success stories, people?

The crux of my conclusion comes after the ---------------------------- .

On 2 Feb 2008, at 4:31 PM, Junio C Hamano wrote:

Actually, I just tried this myself:

   #!/usr/bin/perl -w

   use Term::ReadLine;
   my $term = new Term::ReadLine 'foobar';

   my ($user, $password);
   while (!defined $user) {
           $user = $term->readline("User: ");
   }
   system 'stty -echo';
   while (!defined $password) {
           $password = $term->readline("Password: ");
   }
   system 'stty echo';
   print "You said <$user><$password>\n";
   print "ReadLine backend used was ", $term->ReadLine, "\n";

In my case, the backend was "Term::ReadLine::Perl".  A few
problems:

* After typing "junio <Enter>" to "User:", an extra newline is
  left before "Password:" prompt;

I didn't have this problem.

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

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

-------------------------------------------------

Another example which appears in PerlFAQ #8 uses ReadKey with
its ReadLine, like this:

   use Term::ReadKey;
   ReadMode('noecho');
   $password = ReadLine(0);

which is different from Term::ReadLine's "ReadLine".  An earlier
example you cited from perlfunc.pod's crypt() entry does:

   system "stty -echo";
   print "Password: ";
   chomp($word = <STDIN>);
   print "\n";
   system "stty echo";

In either case, I was worried about the interaction between the
Term::ReadLine backend implementation and "stty".

This got me thinking: At first I wanted to use readline for the  
password prompt,
because I figured it would allow the user better editing facilities,  
especially
with regard to the arrow keys. However, it occurred to me that perhaps  
this should
not be the case; perhaps arrow keys are meant to be useable in  
passwords, etc.

Well, this turns out to be the case! (which may not be a surprise to  
most people,
but it was to me). Passwords can actually contain some of the keycodes  
that read-
line converts into editing commands (now you know which characters you  
don't have
to test when cracking my password). Therefore, we shouldn't even  
bother using the
readline backend for password prompting; neither passwd nor ssh use  
readline, for
example.

I support the 'crypt' method, because the Term::ReadKey approach  
requires another
module dependency.

Sincerely,
Michael Witten

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

Before, when the user sent the EOF control character,
the prompts would be repeated on the same line as the
previous prompt.

Now, repeat prompts display on separate lines.

Signed-off-by: Michael Witten <redacted>
---
 git-send-email.perl |   46 +++++++++++++++++++++++++++++-----------------
 1 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index 14268fc..6724810 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl

@@ -376,9 +376,12 @@ if (@files) {
 my $prompting = 0;
 if (!defined $sender) {
 	$sender = $repoauthor || $repocommitter;
-	do {
+
+	while (1) {
 		$_ = $term->readline("Who should the emails appear to be from? [$sender] ");
-	} while (!defined $_);
+		last if defined $_;
+		print "\n";
+	}
 
 	$sender = $_ if ($_);
 	print "Emails will be sent from: ", $sender, "\n";

@@ -386,10 +389,14 @@ if (!defined $sender) {
 }
 
 if (!@to) {
-	do {
-		$_ = $term->readline("Who should the emails be sent to? ",
-				"");
-	} while (!defined $_);
+
+
+	while (1) {
+		$_ = $term->readline("Who should the emails be sent to? ", "");
+		last if defined $_;
+		print "\n";
+	}
+
 	my $to = $_;
 	push @to, split /,/, $to;
 	$prompting++;

@@ -411,20 +418,23 @@ sub expand_aliases {
 @bcclist = expand_aliases(@bcclist);
 
 if (!defined $initial_subject && $compose) {
-	do {
-		$_ = $term->readline("What subject should the initial email start with? ",
-			$initial_subject);
-	} while (!defined $_);
+	while (1) {
+		$_ = $term->readline("What subject should the initial email start with? ", $initial_subject);
+		last if defined $_;
+		print "\n";
+	}
+
 	$initial_subject = $_;
 	$prompting++;
 }
 
 if ($thread && !defined $initial_reply_to && $prompting) {
-	do {
-		$_= $term->readline("Message-ID to be used as In-Reply-To for the first email? ",
-			$initial_reply_to);
-	} while (!defined $_);
-
+	while (1) {
+		$_= $term->readline("Message-ID to be used as In-Reply-To for the first email? ", $initial_reply_to);
+		last if defined $_;
+		print "\n";
+	}
+	
 	$initial_reply_to = $_;
 }
 if (defined $initial_reply_to && $_ ne "") {

@@ -474,9 +484,11 @@ EOT
 	close(C);
 	close(C2);
 
-	do {
+	while (1) {
 		$_ = $term->readline("Send this email? (y|n) ");
-	} while (!defined $_);
+		last if defined $_;
+		print "\n";
+	}
 
 	if (uc substr($_,0,1) ne 'Y') {
 		cleanup_compose_files();

-- 
1.5.4.9.gcc769-dirty

Whilst convenient, it is most unwise to record passwords
in any place but one's brain. Moreover, it is especially
foolish to store them in configuration files, even with
access permissions set accordingly.

git-send-email has been amended, so that if it detects
an smtp username without a password, it promptly prompts
for the password and masks the input for privacy.

Furthermore, the argument to --smtp-pass has been rendered
optional.

The documentation has been updated to reflect these changes.

Signed-off-by: Michael Witten <redacted>
---

	The backend ambiguity of Term:ReadLine is avoided, and EOF
	is handled for the Password Prompt.

 Documentation/git-send-email.txt |   39 +++++++++++++++++++++++++++++++++----
 git-send-email.perl              |   25 ++++++++++++++++++++---
 2 files changed, 55 insertions(+), 9 deletions(-)

diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0554f2b..4f4caa4 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt

@@ -96,11 +96,40 @@ The --cc option must be repeated for each user you want on the cc list.
 	servers typically listen to smtp port 25 and ssmtp port
 	465).
 
---smtp-user, --smtp-pass::
-	Username and password for SMTP-AUTH. Defaults are the values of
-	the configuration values 'sendemail.smtpuser' and
-	'sendemail.smtppass', but see also 'sendemail.identity'.
-	If not set, authentication is not attempted.
+--smtp-user::
+	Username for SMTP-AUTH. In place of this option, the following
+	configuration variables can be specified:
++
+--
+		* sendemail.smtpuser
+		* sendemail.<identity>.smtpuser (see sendemail.identity).
+--
++
+However, --smtp-user always overrides these variables.
++
+If a username is not specified (with --smtp-user or a
+configuration variable), then authentication is not attempted.
+
+--smtp-pass::
+	Password for SMTP-AUTH. The argument is optional: If no
+	argument is specified, then the empty string is used as
+	the password.
++
+In place of this option, the following configuration variables
+can be specified:
++
+--
+		* sendemail.smtppass
+		* sendemail.<identity>.smtppass (see sendemail.identity).
+--
++
+However, --smtp-pass always overrides these variables.
++
+Furthermore, passwords need not be specified in configuration files
+or on the command line. If a username has been specified (with
+--smtp-user or a configuration variable), but no password has been
+specified (with --smtp-pass or a configuration variable), then the
+user is prompted for a password while the input is masked for privacy.
 
 --smtp-ssl::
 	If set, connects to the SMTP server using SSL.

diff --git a/git-send-email.perl b/git-send-email.perl
index a1a9d14..fec55ea 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl

@@ -157,7 +157,7 @@ my $compose_filename = ".msg.$$";
 
 # Variables we fill in automatically, or via prompting:
 my (@to,@cc,@initial_cc,@bcclist,@xh,
-	$initial_reply_to,$initial_subject,@files,$author,$sender,$compose,$time);
+	$initial_reply_to,$initial_subject,@files,$author,$sender,$smtp_authpass,$compose,$time);
 
 my $envelope_sender;
 

@@ -177,7 +177,7 @@ my ($quiet, $dry_run) = (0, 0);
 
 # Variables with corresponding config settings
 my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
-my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_authpass, $smtp_ssl);
+my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_ssl);
 my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
 my ($no_validate);
 

@@ -214,7 +214,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
 		    "smtp-server=s" => \$smtp_server,
 		    "smtp-server-port=s" => \$smtp_server_port,
 		    "smtp-user=s" => \$smtp_authuser,
-		    "smtp-pass=s" => \$smtp_authpass,
+		    "smtp-pass:s" => \$smtp_authpass,
 		    "smtp-ssl!" => \$smtp_ssl,
 		    "identity=s" => \$identity,
 		    "compose" => \$compose,

@@ -647,9 +647,26 @@ X-Mailer: git-send-email $gitversion
 			die "Unable to initialize SMTP properly.  Is there something wrong with your config?";
 		}
 
-		if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
+		if (defined $smtp_authuser) {
+
+			if (!defined $smtp_authpass) {
+
+				system "stty -echo";
+
+				do {
+					print "Password: ";
+					$_ = <STDIN>;
+					print "\n";
+				} while (!defined $_);
+
+				chomp($smtp_authpass = $_);
+
+				system "stty echo";
+			}
+
 			$auth ||= $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
 		}
+
 		$smtp->mail( $raw_from ) or die $smtp->message;
 		$smtp->to( @recipients ) or die $smtp->message;
 		$smtp->data or die $smtp->message;

-- 
1.5.4.9.gcc769-dirty

A single signal handler is used for both SIGTERM
and SIGINT in order to clean up after an uncouth
termination of git-send-email.

In particular, the handler resets the text color
(this cleanup was already present), turns on tty
echoing (in case termination occurrs during a
masked Password prompt), and informs the user of
of any temporary files created by --compose.

Signed-off-by: Michael Witten <redacted>
---
 git-send-email.perl |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index fec55ea..14268fc 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl

@@ -24,8 +24,6 @@ use Data::Dumper;
 use Term::ANSIColor;
 use Git;
 
-$SIG{INT} = sub { print color("reset"), "\n"; exit };
-
 package FakeTerm;
 sub new {
 	my ($class, $reason) = @_;

@@ -201,6 +199,29 @@ my %config_settings = (
     "aliasesfile" => \@alias_files,
 );
 
+# Handle Uncouth Termination
+sub signal_handler {
+
+	# Make text normal
+	print color("reset"), "\n";
+
+	# SMTP password masked
+	system "stty echo";
+
+	# tmp files from --compose
+	if (-e $compose_filename) {
+		print "'$compose_filename' contains an intermediate version of the email you were composing.\n";
+	}
+	if (-e ($compose_filename . ".final")) {
+		print "'$compose_filename.final' contains the composed email.\n"
+	}
+
+	exit;
+};
+
+$SIG{TERM} = \&signal_handler;
+$SIG{INT}  = \&signal_handler;
+
 # Begin by accumulating all the variables (defined above), that we will end up
 # needing, first, from the command line:
 

-- 
1.5.4.9.gcc769-dirty