Date: Tue, 5 Jun 2012 19:30:32 +0200 From: Frank Dittrich <frank_dittrich@...mail.com> To: john-dev@...ts.openwall.com Subject: Re: Do we need --list=formats? On 06/05/2012 09:21 AM, magnum wrote: > On 06/05/2012 08:29 AM, Frank Dittrich wrote: >> While for bash completion, parsing usage output is fine, a GUI might >> want to list additional information, e.g. FORMAT_NAME and may be even >> implementation details like [128/128 BS SSE2] (so that the user might >> see which formats support OMP...) >> How hard would implementing this be? > > The hardest part may be to decide the exact output format. OK, who should do the hard part? Someone who might want to use it for enhancing the GUI? >> While we are at it: >> Should we also add a --list=subformats, which does the same as >> --subformat=LIST, except that it writes to stdout instead of stderr? > > This is trivial, and dynamic_DISPLAY_ALL_FORMATS() already writes to > stdout. You are right. --encoding=LIST writes to stderr, not --subformat=LIST BTW, do we want to keep in that way, or should --list=encodings do that? >> Then we could discourage the use of --subformat=LIST. >> (My bash completion script could even try to replace --subformat with >> --list=subformats.) >> And in the next release we just get rid of --subformats? > > Yes. We could pull it from the usage blob immediately and drop the > support later. We might add --list to the usage instead, with a > description like: > > --list=WHAT List capabilities, see doc/OPTIONS or --list=? ...and remove --list=NAME from --list=hidden-options... I think this would be a good idea. 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.