[1485] in Kerberos_V5_Development
kdb5_util usage
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Fri Aug 2 14:13:01 1996
Date: Fri, 2 Aug 1996 14:11:18 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
After thinking about it a little bit, I decided the problem with
kdb5_util's current usage is the varying ways that commands inherit
option state from the command line; some do, some don't, and some
inherit only some of their options. Very confusing. I think the
reason for the confusion is that the program uses an ss paradigm.
Since all the commands take some options in common (like -d), it
seemed silly to have each ss sub-command parse them (and require the
user to enter them); therefore I put made them options to the program.
But then each sub-command also has its own unique options that it had
to take directly.
In fact, though, you pretty much never want to perform more than one
of create, destroy, dump, or load at a time (create and stash are
often performed together, but create now has a stash option). Thus
there is no good reason for kdb5_util to use ss at all. I suggest the
following cvs-like usage:
kdb5_util command [-r realm] [-d dbname] [-k mkeytype] [-M mkeyname]
[-m] [command options]
commands are:
create_db [-s]
destroy_db [-f]
stash_mkey [-f keyfile]
dump_db [-old] [-ov] [-b6] [-verbose] [filename
[principals...]]
load_db [-old] [-ov] [-b6] [-verbose] [-update] filename
dump_v4db [filename]
load_v4db [-t] [-n] [-K] [-f] inputfile
kdb5_util takes options that apply to all sub-commands, a sub-command,
and sub-command-specific options. There is no ss loop, so each
invocation of kdb5_util performs exactly one sub-command and then
exits. All options are position-independent.
Comments?
Barry
