[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <40b144f4a72a5570cf174fa99153b0fa@smtp.hushmail.com>
Date: Sun, 13 May 2012 00:22:00 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Fwd: bash auto-completion for john
On 05/12/2012 10:37 PM, Frank Dittrich wrote:
> On 05/12/2012 01:45 AM, magnum wrote:
>> On 05/11/2012 09:44 PM, Frank Dittrich wrote:
>>> For --rules= and --single=, I'll do the same.
>>> Non-jumbo versions don't allow optional parameters for -rules and
>>> single, but there might exist "older" jumbo versions which allow
>>> parameters for --rules and --single, but don't have --list=...
>>
>> IMHO, I'd say we should (care to) support latest core and latest Jumbo
>> (in this case). Sure, the better we support old Jumbos, the better. But
>> let's not put hours of work for seconds of benefit.
>
> Trouble is, the completion rules will work for any executable called john:
> john
> ./john
> /usr/bin/john
>
> Once a user installs the latest jumbo and copies the bash completion
> file to /etc/bash_completion.d/, the same completion logic will also
> work for a system-wide john which has been installed as a package of the
> linux distribution.
> So I don't know whether we should care about this.
True, we should handle this the best we can. I just mean it might not be
worth it to implement tedious workarounds or hardcoded lists. If
"--list=nnn" fails, just present (for example) some terse usage output
like "--rules=<section>" (literally).
Also, I have mixed feeling about hard-coded lists. If you hard-code
"appendluhn" and the user runs an older version not having that, it will
be very confusing.
> In these cases, expansion with correct List.Rules section names from the
> config file specified works correctly.
>
> ./john -co=test.conf --rules=
> ./john --rules=w --conf:john.conf
This is great. I was going to test that but I forgot it. I just tested
john --conf=x --list=y
> If I specify more than one config file, the last one is used for rules
> completion:
>
> ./john --config=john.conf --config=fd.conf --rules=
>
> will list the rules sections from fd.conf.
Let's just ignore these quirks. git completion was my benchmark for
awesomeness and it too can be fooled easily if you really want to.
> Now it is not even necessary to put the file john.bash_completion into
> the /etc/bash_completion.d/ directory.
>
> Adding the line
> . <path_to_john_source_directory>/john.bash_completion
> to ~/.-bashrc is all that's needed to make bash completion for john and
> unique work.
This is great. It probably means we do not want Alex to install bash
completion on bull, because if we run it ourselves from a chosen
directory, it may be more updated.
Or... what happens if we have an older version in /etc/bash_completion.d
and I run a newer local one? It just over-rides the older with no bad
side effects?
> Should we discuss possible changes in the completion logic here, or on
> john-users?
Actually john-users may be a better choice.
> E.g., currently I use this expansion logic:
>
> $ ./john -in
> Pressing [tab] changes -in to --incremental.
>
> For --incremental, there are two possible completion implementations.
>
> The first one:
>
> $ ./john --incremental
> Pressing [tab] changes --incremental to --incremental=
>
> $ ./john --incremental=
> Pressing [tab] twice lists these options:
>
> $ ./john --incremental=
> all all15 all6 all7 all8 alnum alpha digits
> digits8 lanman
>
> This means, the only indication that --incremental is a valid option
> even without adding =value is that the first completion step for -in
> results in --incremental, not --incremental=.
>
> (For -ex on the other hand, pressing [tab] immediately will result in
> --external=, because --external requires a value.)
>
>
> The other implementation would provide these options for a non-jumbo
> version):
>
> $ john --incremental
> --incremental --incremental=Alpha
> --incremental=All --incremental=Digits
> --incremental=Alnum --incremental=LanMan
I was going to say I like this better...
> For --incremental, the user would have to type the '=' manually, to get
>
> $ ./john --incremental=
> all all6 all8 alpha digits8
> all15 all7 alnum digits lanman
>
> after pressing [tab] twice.
But personally I do not like having to give an explicit '=' so I prefer
the other implementation (if I got this right).
> We should probably decide which behavior is better and unify it for the
> expansion of --rules (jumbo only), --single (jumbo only),
> --incremental, --restore and --status (session names derived from .rec
> files) .
> (Of course, I could also allow a user specific configuration of the
> behavior. But may be this is overkill.)
Yes it may. OTOH, if you are having fun when implementing it, no harm
done :)
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.
