[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP2331AEA0AC5A474563AEF8BFD0C0@phx.gbl>
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.
