[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 May 2012 02:42:48 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Fwd: bash auto-completion for john
On 05/09/2012 01:15 AM, magnum wrote:
> On 05/09/2012 12:31 AM, Frank Dittrich wrote:
>> OK. Currently implemented:
>>
>> 1.
>> Improved expansion for --config= (only files *.conf and *.ini will be
>> suggested; IMO this is what sane people would want to have, even if you
>> could also name your config file john.log)
>> Negative side effect: expansion for ~ doesn't work anymore, but that is
>> probably less important. (I hate doing this "manually", there really
>> must be another way. The code is already full of ugly hacks, no need to
>> add even more of them.)
>
> Is your very first approach, with "complete -F _filedir_xspec john" not
> usable together with auto-completion?
No, because the
complete -F _filedir_xspec john
in my .bashrc would overwrite the
complete -F _john john
at the end of the bash completion script.
you can check the effect with
complete -p|grep john
>> For proper support of --incremental=, --external=, --rules=, --single=,
>> I think we need a hidden option in john to get those lists (2 different
>> lists for --external; one for modes with generate() function, one for
>> modes without) in an easy to parse way.
>
> Maybe I'll get time to have a look at this soon-ish. So at a minimum we
> need the following:
>
> --list=incremental
> --list=ext-modes (external w/ generate)
> --list=rules
> --list=filters (external w/o generate)
Yes. If splitting external modes is too hard, just one list will do.
(The two separate lists are only needed when I start interpreting other
command line options. But I never intended to write a bash completion
script for john which is larger than the one for git.
But may be these separate lists are needed for the GUI as well.)
> Maybe some of this is overkill. I find the very version you have now
> terrific, and if we just support rules, external modes and filters it
> will be awesome. Those three things are what I most often forget. For
> example, I often "grep 'List\.Rules:' john.conf" to get the a la carte menu.
I also use
grep "^\[List\.Rules:" john.conf
regularly.
> BTW I had an idea of just filling in a static usage hint for some
> options when tabbed. Like for markov mode, if you tab again it could
> just give a static "--markov[=LEVEL[:opts]]" instead of the current
> "--markov" below the actual command line. If this is possible?
That won't work, because it is just one possible option.
Since the completion logic would take over the common part of all
matching options into the command line, you'd end up with
--markov[=LEVEL[:opts]] on the command line.
But this works:
$ ./john --markov
--markov --markov=LEVEL[:opts]
Unfortunately, I can't (or don't know yet how to) add "(see doc/MARKOV
for details)" to the tab completion options, because this would be
interpreted as separate completion options which get dropped because the
(to be completed) word "--markov" existing on the command line doesn't
match the other "options".
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.
