Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 5 Jun 2012 19:30:32 +0200
From: Frank Dittrich <>
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.


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.