#26 GPG Keychain Access does not pass path to Terminal
When using Keychain Access to, for example, sign a key locally, the programme opens Terminal and attempts to run the appropriate command. It does not, however, appear to pass the path to gpg with the command. This results in an error message saying that gpg cannot be found, although retyping the command with the correct prefix (/usr/local/bin/ in this case) resolves the issue.
Behaviour observed with latest version of Keychain Access (7.0.1), GPG 1.4.3 on Mac OS 10.3.9 and 10.4.6. (Note that we are not using the precompiled binary verion of GPG itself as 1.4.3 was not available when we installed.)
If Keychain Access knows where gpg is - and it clearly does as other functions work fine - surely it should pass the full path to Terminal when executing the command?
Logged In: YES
user_id=1265550
I am running Keychain Access (7.0.1) and gpg 1.4.3 under OS
10.4.6 (compiled from source) and I don't experience the
problem you describe.
If you have to type /usr/local/bin/gpg to access gpg
--lsign, then the same syntax would be required for any
other action requiring gpg.
Have you checked whether /usr/local/bin is included in your
PATH?
$ cat /etc/profile
Charly
Logged In: YES
user_id=643832
Yes, I realise that. I don't have the problem on my own
machine, and I don't use Keychain Access anyway except for
testing.
My point is that users utilising the graphical tools are
likely to be users who do not use the command line. Keychain
Access clearly knows where gpg is, since it is possible to
do things which do not require the Terminal just fine
(e.g. generating a new key pair, importing keys etc.)
Obviously the need to go to the Terminal at all is
unfortunate in a tool designed to make this unnecessary.
However, eliminating this is obviously complex. What would
not be complex however, would be designing Keychain Access
to put the full path to gpg into the command it executes in
Terminal, so that users who are wary enough of the command
line already, do not immediately meet with an error they are
unlikely to understand.
I'm not asking for a solution to the problem on their
machines. It is obviously how to solve it if one is
familiar with the command line. The users I'm working with,
however, are deeply mystified by it and have no idea what is
wrong. To them, it is an error message - that is, another
programme which doesn't work. The point is not that I cannot
solve it in the case of these particular users. Rather, I'm
suggesting that this shouldn't be necessary. It would surely
be easy to have Keychain Access simply execute the command
with the full path to gpg? Most graphical interfaces follow
this practice if they need to actually run something in
Terminal, since their target audience consists of just those
users unlikely to be familiar with the Terminal or the shell
in the first place.
I just thought it might be a simple way to make it slightly
more usable by those unfamiliar with the command line which
is, as I understand it, one of the goals of the project.
I wanted to look at it myself, but I'm not sure where to
find the source code for GPGFileTool or Keychain Access.
Logged In: YES
user_id=1265550
I believe you could find the source codes of GPGFileTool and
GPG Keychain Acess in CVS. I hope the concerned authors or
maintainers will address your queries.
As an end-user (I am not a programer, know little about
Unix, and just very basic things about CLI), I have had to
cope a few times with Terminal telling me that 'gpg not
found', or something similar. I taught myself to find and
solve the problem: the path to gpg executable was not
included in my PATH, due to some singularity in the
composition of the source code elements, or something else
of which I have no clear comprehension.
I know that the use of GPGPreferences sets, by default, the
executable path to gpg, but I don't believe it also sets it
in the user's PATH. Likewise I don't believe that GUI
helpers or applications like GPG Keychain Access can
actually look for gpg when it is not found in its default
location. But that's an issue that should be addressed, as I
wrote previously, by the authors or maintainers of such
applications.