Libcurl (was Re: [Announce] GnuPG 1.4.1 released)

[Carlo Luciano Bianco]

Il /23 mar 2005/, *David Shaw* ha scritto:

> Thanks for running that test.  I can see what happened now.  It's
> amusing that this comes up so many years later, and it seems nobody
> noticed.

Well... Consider that 99% of Win32 GnuPG users has a statically linked 
executable and that, moreover, 99% of the remaining ones keeps the dlls in 
GnuPG folder. So I was the only one who could have this problem... ;-)

> When starting a keyserver subprocess, GPG sets the path to where the
> subprocess binary exists (in your case c:\programmi\gnupg).  In doing
> so, it removes the earlier %PATH%.  This is intentional, as I did not
> want to search the whole PATH for a program named 'gpgkeys_xxx', and
> run the risk of running the wrong one.

OK, I agree with you on this. Just looking the entire PATH for a keyserver 
helper is far too risky...

> This is easy to fix, but I need to think for a moment on which fix is
> best and keeps the current semantics of exec-path.

Maybe it is possible to run the keyserver helpers not just by their name, but 
by their *entire* name: instead of running "gpgkeys_xxx.exe", gpg.exe should 
run "c:\programmi\gnupg\gpgkeys_xxx.exe". In other words, instead of putting 
its own folder in the PATH, gpg.exe should put its own folder in front of the 
name of the keyserver helper to be executed.

In this way you should be pretty sure that you execute the right file, and 
you can keep the system PATH as it is. But maybe it is not so simple...

In any case, thank you again for all your help!
Carlo Luciano

-- 
| Carlo Luciano Bianco | ICQ UIN: 109517158                              |
|______________________| Home page: <http://clbianco.altervista.org/>    |
|GPG DSA/ElG 1024/4096:|_________________________________________________|
|KeyID:0x5324A0DA - Fingerprint:8B00C61034120506111B143DEDBF71B45324A0DA |