On Sat, 2009-05-30 at 23:16 -0400, Steven W. Orr wrote: > Whatever program you're using that is invoking gpg has the DISPLAY > variable set. What you can do is to create a shell wrapper that shuts > DISPLAY off. e.g., I'm running alpine, so I *could* create an alpine > command a la > > #! /bin/bash > unset DISPLAY > /usr/bin/alpine "$@" > exit > > The only caveat is that whatever program you use will suffer the loss of > access to your entire DISPLAY, not just pinentry
I'm using rxvt-unicode and GNU Screen combo.
As I stated, "I'm invoking gpg from the command line shell."
Interesting hack, but this is going to kill my command line experience
when I type "gvim"!
Notice, vim & gvim have an option to call either or, and if X isn't
present, falls back to vi/vim?
This is probably what pinentry should do, instead of depending on X (gtk
or qt3) explicitly.
---snip---
if {environmental variable is set to console/gtk/qt3}
use the specified pinentry flavor
else use pinentry-console
else use pinentry-gtk
fi
---snip---
A good place for this environmental variable is within
$HOME/.gnupg/options.
This way, there's a fallback to the fallback method as there is no
telling where a user or what X application is going to invoke gpg.
Well, obviously there is, but it hinders those working in a shell doing
simple task with gpg!
I'm guessing, the current solution is to assume the user is a dumb X
user. ;-)
(I use both, command line for gpg, as well as Evolution for email which
is set to only call pinentry-gtk-2.)
From searching on the web, there's quite a few others griping about this
same issue.
--
Roger
http://rogerx.freeshell.org
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
