From: Junio C Hamano <gitster@pobox.com>
To: Michael Witten <mfwitten@MIT.EDU>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] git-send-email: ssh/login style password requests
Date: Fri, 01 Feb 2008 02:09:54 -0800 [thread overview]
Message-ID: <7vodb19edp.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <1201841954-17949-1-git-send-email-mfwitten@mit.edu> (Michael Witten's message of "Thu, 31 Jan 2008 23:59:14 -0500")
Michael Witten <mfwitten@MIT.EDU> writes:
> +--smtp-pass::
> + Password for SMTP-AUTH. The default value can be specified
> + with the configuration variable 'sendemail.smtppass' or
> + sendemail.<identity>.smtppass (see sendemail.identity).
> + The argument is optional: If no argument is specified, then
> + the password is assumed to be the empty string.
> + If a username has been set, but no password has been set,
> + the user is prompted for a password with masked input for
> + privacy; passwords need not be recorded in configuration
> + files.
I am a bit puzzled about the above description, though. It is
not clear if there is any difference between "the empty string"
password, and "no password has been set". It makes me wonder
what the possible cases are.
(1) no *.smtppass configuration present; no --smtp-pass parameter
is given on the command line.
(2) *.smtppass configuration present but is an empty string; no
--smtp-pass parameter is given on the command line.
(3) *.smtppass configuration present with a non-empty string; no
--smtp-pass parameter is given on the command line.
(4) parameter is given with an empty string (i.e. "--smtp-pass=")
on the command line.
(5) parameter is given with a non-empty string (i.e. "--smtp-pass=foo")
on the command line.
My _guess_ is that command line always trump configuration so
in cases (4) and (5) it does not matter what you have (or do not
have) in *.smtppass configuration. In other cases, lack of *.smtppass
and having *.smtppass with an empty string as its value are equivalent.
And in any case, an empty string (or lack of specification) results
in prompting.
But you shouldn't make _me_ guess. You certainly would be
forcing many other people to guess with this.
> + if (defined $smtp_authuser) {
> +
> + if (!defined $smtp_authpass) {
> +
> + system "stty -echo";
> +
> + do {
> + $_ = $term->readline("Password: ");
> + } while (!defined $_);
> +
> + system "stty echo";
> +
> + $smtp_authpass = $_ if ($_);
> + }
> +
I like what the patch tries to do, but the system() there feels
a tad ugly. In addition it makes me wonder (1) what happens if
you ^C out from this while loop, and (2) $term->readline()
interface might already have a method to turn echo off.
We luckily have people handy at Perl on the list, so I'll wait
for our resident Perl experts to suggest a better alterantive.
We are not in a hurry, so I expect a polished resubmit after
1.5.4. Thanks.
next prev parent reply other threads:[~2008-02-01 10:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-01 4:59 [PATCH] git-send-email: ssh/login style password requests Michael Witten
2008-02-01 10:09 ` Junio C Hamano [this message]
2008-02-01 18:38 ` Michael Witten
2008-02-01 22:42 ` Michael Witten
2008-02-01 23:34 ` Junio C Hamano
2008-02-01 23:42 ` Michael Witten
2008-02-02 1:27 ` Junio C Hamano
2008-02-02 4:06 ` [PATCH 1/2][Perlers?] " Michael Witten
2008-02-02 4:06 ` [PATCH 2/2][Perlers?] git-send-email: SIG{TERM,INT} handlers Michael Witten
2008-02-02 21:31 ` Junio C Hamano
2008-02-02 21:31 ` [PATCH 1/2][Perlers?] git-send-email: ssh/login style password requests Junio C Hamano
2008-02-03 17:59 ` Michael Witten
2008-02-03 20:59 ` Michael Witten
2008-02-04 0:53 ` [PATCH 1/3][V.2] " Michael Witten
2008-02-04 0:53 ` [PATCH 2/3][V.2] git-send-email: SIG{TERM,INT} handlers Michael Witten
2008-02-04 0:53 ` [PATCH 3/3][V.2] git-send-email: Better handling of EOF [^D] Michael Witten
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vodb19edp.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mfwitten@MIT.EDU \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).