[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 2 Jul 2012 22:14:39 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New -list function added to bleeding. -list=format-methods
On 07/02/2012 07:31 PM, jfoug wrote:
> The syntax is --list=format-methds[=WHICH]
s/methds/methods/
But the patch itself is correct.
If one can use --list=... and --list:... (as with other options,
shouldn't we also allow --list:format-methods:WHICH or
--list=format-methods:WHICH
And may be mention --list=format-methods[:WHICH] in the documentation?
For --list=format-methods, the bash completion will work without
problems, but it will add a trailing space after format-methods.
So I'll need to update the bash completion script in that case.
(I'll take care of that once the "final" implementation for
--list=format-methods is ready.)
If you would change "format-methods, " in the --list=? output to
"format-methods[:WHICH], ", then I could implement something more
general which will even work for future additions with an (optional or)
obligatory :VALUE, so that a trailing space will not be added by the
bash completion if there is an optional value.
(If an obligatory value is required, the completion could even add the
':' or '=', otherwise I'll use logic similar to the current one for
--options with an optional value.)
Currently, the list of methods (possible values for WHICH) is hard coded.
I could either hard code the same list in john.bash_completion, or we
would need another --list=method-names (or similar) option which I could
use to provide bash completion.
(If that new option doesn't exist, then I can fall back to the hard
coded list.
But if the list of method names varies in future releases, an hard coded
list for the latest release would provide completions which are not
supported by older releases.
If someone specifies --list=format-methods:invalid_name, I'd prefer an
exit(1).
BTW, I also have a patch ready to make the --list= more user friendly
(e.g., for --list=help or --list=whatever, I print the same list as with
--list=?, as long as no such section name is defined in the config
file), but that will conflict with your change.
Fortunately, my patch is against magnum-jumbo, so I'll let magnum fix
the merge conflict.
(I would have sent the patch a few days ago, but he insists on a pull
request;)
> One other 'feature', is the code will also print if any of the get_hash or
> binary_hash function pointers are null. The format self test code fails
> for any format for any of the other pointers IF they are null, so I did not
> replicate that code here.
What if a format doesn't have any self tests?
(I guess the format will not work anyway, and that's why such a format
will probably not be part of a released jumbo version.)
Frank
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
