All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rafael Gieschke <rafael@gieschke.de>
To: kusmabite@gmail.com
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] compat: add a getpass() compatibility function
Date: Thu, 19 May 2011 19:01:35 +0200	[thread overview]
Message-ID: <EC81F772-7149-40A0-891A-973C886AB052@gieschke.de> (raw)
In-Reply-To: <BANLkTinPHeSfZXRb7pqt7-XWkR5fH=wAjg@mail.gmail.com>


Am 19.05.2011 um 14:17 schrieb Erik Faye-Lund:

> But I can't help to think that this implementation of getpass looks a
> bit heavy, especially since we already have our own getpass
> implementation in compat/mingw.c.

> Do we really need two implementations? Wouldn't it be better to factor
> out the mingw-version to a separate source file, and then improve it?

Yes, I agree very much that it would be nicer to have a common version.


> Windows doesn't have /dev/tty, but the logic in this version handles
> that by using stdin/stderr instead. The signal-stuff has a comment
> that indicates it might not even be correct. tcgetattr/tcsetattr isn't
> supported on Windows, but it's not needed if we use getch (as the
> version in compat/mingw.c does). POSIX/curses getch respects the
> echo-setting, while Windows getch never echo.

Sadly, there is no curses.h on Android. So as my goal is compiling on Android, it wouldn't help much to create another dependency on curses.h.

So we would still need the /dev/tty opening and the tcgetattr/tcsetattr stuff, which would result in a very cluttered code if combined with getpass from compat/mingw.c. So I think, it will be easier to keep the two separated.

I do share your concern about the license and the heavyness of the code, so I switched to the getpass.c from uClibc and prepared a new patch. It is LGPL-v2.1 licensed, which seems like it has to be added anyway. I also tried to remove unused code from the new version as good possible.

  parent reply	other threads:[~2011-05-19 17:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-19 11:37 [PATCH] compat: add a getpass() compatibility function Rafael Gieschke
2011-05-19 12:17 ` Erik Faye-Lund
2011-05-19 16:30   ` Junio C Hamano
2011-05-19 17:01   ` Rafael Gieschke [this message]
2011-05-19 17:27     ` Junio C Hamano
2011-05-19 18:07       ` Erik Faye-Lund
2011-05-19 19:16         ` Rafael Gieschke
2011-05-19 19:19           ` Erik Faye-Lund
2011-05-19 19:42             ` Rafael Gieschke
2011-05-19 20:12               ` Erik Faye-Lund
2011-05-19 21:16                 ` Erik Faye-Lund
2011-05-20 10:06                   ` Rafael Gieschke
2011-05-20 10:48                     ` Erik Faye-Lund
2011-05-20 17:18                       ` Junio C Hamano
2011-05-20 17:26                         ` Erik Faye-Lund
2011-05-19 12:21 ` Erik Faye-Lund
2011-05-19 15:14   ` Jonathan Nieder
2011-05-19 15:29     ` Erik Faye-Lund
2011-05-19 17:17     ` Junio C Hamano

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=EC81F772-7149-40A0-891A-973C886AB052@gieschke.de \
    --to=rafael@gieschke.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kusmabite@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.