[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 09 May 2012 01:15:27 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Fwd: bash auto-completion for john
On 05/09/2012 12:31 AM, Frank Dittrich wrote:
> On 05/08/2012 09:59 PM, magnum wrote:
>> Wow. This is better than I expected in this short time. Excellent! I'll
>> commit this along with a make rule for installing.
>
> Your Makefile changes are rather optimistic, or am I missing something?
>
> $ cp test /etc/bash_completion.d/
> cp: cannot create regular file `/etc/bash_completion.d/test': Permission
> denied
I think most (perhaps all) Makefile's I have seen will just fail with no
grace if you do a "make install" as a user. But nevermind that, of
course we can catch errors. And on error, output a suggestion to run
this specific target w/ sudo.
> BTW, on my system, for user root cp is an alias:
> # alias cp
> alias cp='cp -i'
When called from Makefile, I would think not. Actually I believe these
aliases are not even active when running commands with sudo.
> Better don't mess with /etc/bash_completion.d, and just write
> instructions how to enable bash completion for john?
Personally I find that a terrible idea :) but I will add some error
checking.
>> If/when you update it further, just post it here and I'll update git.
>
> 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?
> 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)
> If we want to enhance completion support even more, we might want to get
> more detailed information about individual hash formats
> (salted, not salted, maximum password length, ...)
> Some of the information can be obtained from running
> john --format=xyz --test=n from within the bash completion script.
> But I'm not sure I want to do it.
> (I could run --test=100 and redirect all output to /dev/null on
> arbitrary user error, say when the user specified a non-existing option
> on the command line ;)
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.
Also, time will tell what we really miss. These kinds of things are
addictive. I really hate it when I encounter systems without git completion.
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?
magnum
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.
