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.