[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP1241D41F519536305B15294FDEF0@phx.gbl>
Date: Thu, 5 Jul 2012 20:45:38 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Should we add --make_check to --list=hidden-options?
On 07/05/2012 08:16 PM, Solar Designer wrote:
> As to adding it to --list=hidden-options, I don't mind, but I see little
> need. It is meant to be used by "make check" only.
Today I saw a useful difference to --test=0:
--make_check doesn't test the user defined dynamic formats. It doesn't
read the config files, and apparently also works with a broken config.
So far, --make_check is also the only option using an underscore in the
name.
And opposed to other options with an ambiguous abbreviated name,
the existence of --make_check doesn't prevent --make=filename.chr from
working. That's probably because --make_check isn't part of the usual
option handling, e.g., it is also impossible to use an abbreviated
option name like --make_ch to invoke the "make check" functionality.
If this will be true even for future john versions, I have to take this
into account if I ever switch to a generic approach in john.bash_completion.
The idea is to avoid ugly patterns like this one:
-?(-)m?(a|ak|ake|ake-|ake-c|ake-ch|ake-cha|ake-char|ake-chars|ake-charse|ake-charset)+(=|:)*)
And also to get rid of the hard coded tests for uniqueness of
abbreviated option names, by automatically generating mappings of
abbreviated option names to their full names - as long as the
abbreviated option name is still unique.
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.
