Extracting valid content; command line use of --edit-key

[Michael Young]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks to both Timo and Werner for the quick answers.  I should
have realized that other input was being taken from the command
line, given the hanging/saving behavior.

From: Werner Koch <wk at gnupg.org>
> Let me stress that you MUST act on the GET_* status lines and stop
> processing if you encounter a line which you don't understand (you may
> try to send just an empty line in such a case so a default can be
> used).  The rationale is that --edit-key is an interactive menu driver
> command which may change from version to version; for example the
> current snapshot might issue some new prompts when signing a key.

I was really hoping that the command-line form of "--edit-key" would
be less interactive, particularly in the presence of a "--batch"
setting.  I want a "do what I say without asking any questions" form.

If one MUST act on the status lines, then there is no legitimate
way to put "--edit-key" parameters on the command line -- it has
to be formulated before seeing any of the status material.  But
command-line parameters are clearly accepted.

In order to make command-line parameters usable, I would:
    take only the menu commands and their fixed parameters on the
      command-line;
    use the existing status mechanism for any confirmations or
      questions (including commands if the command line has none); and,
    abide by the "--yes" and "--batch" switches whenever possible.
- From Timo's answer, it sounds like he doesn't use command-line
menu commands, so he wouldn't be affected.

I'm not asking for much, am I? :-)

In the meanwhile, I'll probably just take my chances on the
interactive sequences changing.  It might just be easier to write
my own packet-cruncher than a status parser.

Speaking of parsing and such, is it safe to assume that the uid lines
in the "--with-colons" form appear in the same order as in the
"--edit-key" listing?  If it is not, then that's yet one more thing
I'd have to parse.  The whole point to --with-colons is to simplify
parsing, so I'm guessing/hoping that the answer is "yes".

Thanks again for your help!

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPKoMPFMkvpTT8vCGEQLbzgCgv5rNJwkiEMZp42GrrOaImt19rYsAnRpK
NNTpPwJu0ffgd0znFg2MBJm+
=yovD
-----END PGP SIGNATURE-----