2nd Try: --fd-status and stderr msgs from gpg
Leigh S. Jones
kr6x@kr6x.com
Thu May 23 16:06:01 2002
Your solution is looking right at you:
If you do not get the "_OKAY" in your status_fd stream then your
operation has failed. If you want to find out why, then capture
stderr and search the text for key phrases such as "key not found".
But if you would take no particular action if "key not found" was
present in the stderr stream, then don't searcy for it. Stderr is not
difficult to capture, just place a 2 >> [filename] on the command
line and read the contents of [filename]. Or pipe the stderr
straight into your program.
If you'd like quicker answers for questions like this, try telling us
what operating system you are running. From your original post
it's difficult to tell if you are running Linux, Unix, or Windows.
----- Original Message -----
From: "Joerg Toellner" <toellner@oss-gmbh.de>
To: <gnupg-users@gnupg.org>
Sent: Thursday, May 23, 2002 5:13 AM
Subject: 2nd Try: --fd-status and stderr msgs from gpg
> Hello List,
>
> as im not having received a line for my problem posted a week ago,
please
> allow me to do a second try. I cant believe, that nobody here has
handled
> the --status-fd and can point me in the right direction.
>
> Summary of my problem as posted last week:
> ------------------------------------------
> I use gpg in our mailserver-gateway for our lan in an unattendet
environment
> from within some perl scripts. All outgoing mails should be
encrypted by gpg
> for every email-adress (used as the uid) where a public key is
present in
> the pubring.
>
> To decide (in my perlscript which opens gpg where necessary) whether
the
> operation was succesful or not i capture --fd-status and the stderr
from
> gpg. I listen on the --status-fd, get there the well formatted
gpg-msgs
> (described in File DETAIL) and interpret this msgs to decide what to
do
> next.
>
> The problem is, that there are errors that are NOT reported on
> the --status-fd but at the stderr. And this msgs are really ugly to
> interpret (ok they are more human readable but this is not my
intension).
>
> EXAMPLE:
> if i decrypt i file i got alot of msgs (DECRYPTION_STARTED,
DECRYPTION_OKAY
> or DECRYPTION_FAILED a.s.o.) from the --status-fd prefixed with
[GNUPG: ]
> into my perlscript. All okay here.
>
> But if i export a key in armor mode for sending it via email to
someone and
> the key is not present (for what reason ever), i got *NO* msgs on
the
> --status-fd but on the stderr there is a output that says: blah blah
key not
> present.
>
> The operation has failed and no msg on --status-fd appears in this
case
> indicating the error :-(. Even as there is a msg for this case
> for --status-fd (see File DETAILS) named NO_PUBKEY.
>
> Do i sth. wrong. I thought its enough to listen on --status-fd to
know all
> about gpgs actual workflow. I really dont want to interpret the
stderr
> output in addition to the --status-fd if i can avoid it.
>
> Please! This is my second try to get an answer. Be kind and give me
some
> lines back this time. Im sure there are some good guys in this list
that
> have managed the error-interpretation for gpg in their scripts and
can give
> me a little hint.
>
> PLEASE! TIA!
> Joerg Toellner
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users