Rafael Gieschke [off-list ref] writes:
quoted hunk
diff --git a/connect.c b/connect.c
index 57dc20c..15b285e 100644
--- a/connect.c
+++ b/connect.c
@@ -632,7 +632,11 @@ char *git_getpass(const char *prompt)
if (!askpass)
askpass = getenv("SSH_ASKPASS");
if (!askpass || !(*askpass)) {
+ #ifndef NO_GETPASS
char *result = getpass(prompt);
+ #else
+ char *result = NULL;
+ #endif
if (!result)
die_errno("Could not read password");
return result;diff --git a/ident.c b/ident.c
index 1c4adb0..76fa786 100644
--- a/ident.c
+++ b/ident.c
@@ -20,7 +20,12 @@ static void copy_gecos(const struct passwd *w, char *name, size_t sz)
* with commas. Also & stands for capitalized form of the login name.
*/
- for (len = 0, dst = name, src = w->pw_gecos; len < sz; src++) {
+ #ifndef NO_PW_GECOS
+ src = w->pw_gecos;
+ #else
+ src = "&";
+ #endif
+ for (len = 0, dst = name; len < sz; src++) {
int ch = *src;
if (ch != '&') {
*dst++ = ch;
Please do not throw in conditional compilation in a codepath that is
otherwise generic.
Do something like this near the beginning of the file (or if they are
common, in an appropriate header):
#ifdef NO_GETPASS
#define getpass(ignored) NULL
#endif
#ifdef NO_PW_GECOS
#define get_gecos(ignored) "&"
#else
#define get_gecos(struct_passwd) (struct_passwd->pw_gecos)
#endif
That way, you do not have to change connect.c at all, and the code that
accesses gecos field would get a slight abstraction, i.e.
for (len = 0, dst = name, src = get_gecos(w); len < sz; src++) {
...
I however suspect that NO_GETPASS would be a useless thing in the longer
term. Wouldn't you rather wish to have a native Android UI that asks a
password and plug that implementation as a replacement for git_getpass()?
It might be worthwhile to study how mingw folks do this part before you
dive in and butcher this codepath in a way you may regret later.
Am 16.05.2011 um 23:11 schrieb Junio C Hamano:
Please do not throw in conditional compilation in a codepath that is
otherwise generic.
Do something like this near the beginning of the file (or if they are
common, in an appropriate header):
#ifdef NO_GETPASS
#define getpass(ignored) NULL
#endif
#ifdef NO_PW_GECOS
#define get_gecos(ignored) "&"
#else
#define get_gecos(struct_passwd) (struct_passwd->pw_gecos)
#endif
That way, you do not have to change connect.c at all, and the code that
accesses gecos field would get a slight abstraction, i.e.
for (len = 0, dst = name, src = get_gecos(w); len < sz; src++) {
...
Thanks. Great idea, didn't think about that. See new patch.
I however suspect that NO_GETPASS would be a useless thing in the longer
term. Wouldn't you rather wish to have a native Android UI that asks a
password and plug that implementation as a replacement for git_getpass()?
It might be worthwhile to study how mingw folks do this part before you
dive in and butcher this codepath in a way you may regret later.
I don't think that it is a lot of fun to call Android UI code from C as it is normally only done from Java.
The same problem occurs in dropbear on Android. There, it is solved by including a NetBSD version of getpass.c: https://github.com/CyanogenMod/android_external_dropbear/blob/master/netbsd_getpass.c .
If including NetBSD code is okay, the new patch will work. There currently is very limited use for this on Android, however, as there is no libcurl by default on Android. So, the only usage is git-imap-send, which works fine with this patch.
Compiling libcurl for Android should be possible with some work, though. So compat/getpass.c would be used for libcurl/HTTP access, too.
On Tue, 17 May 2011, Rafael Gieschke wrote:
Compiling libcurl for Android should be possible with some work, though. So
compat/getpass.c would be used for libcurl/HTTP access, too.
(lib)curl already has a dedicated makefile in the release tarball crafted for
building it for Android. It should not be a major obstacle.
--
/ daniel.haxx.se
Am 17.05.2011 um 08:44 schrieb Daniel Stenberg:
(lib)curl already has a dedicated makefile in the release tarball crafted for building it for Android. It should not be a major obstacle.
Thanks, I'll have a try but the instructions in Android.mk look kind of scary :-).