Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 09 May 2012 01:15:27 +0200
From: magnum <>
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

>> 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=ext-modes  (external w/ generate)
--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?


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.