Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 May 2012 02:27:59 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Fwd: bash auto-completion for john

Hi all,

this started on john-users (that's why the last john-users mail on this
topic is appended full-quoted), meanwhile it might be more on topic in
john.dev.

The Q&D solution to support bash completion for
--wordlist=filename_starting_with_a_tilde
was to add a line to ~/.bashrc:
complete -F _filedir_xspec john

Proper bash completion support for john needs much more effort.


But here is a first humble attempt to support expansion of option names
and expansion of file names for options --wordlist=, --config=, --pot=,
and --make-charset= (the last option probably should be ignored, to make
accidentally overwriting files harder).

If the current word doesn't start with -, filename expansion is used.


This is still more or less a q&d proof of concept.
Current limitations, TODOs and FIXMEs are mentioned in the attached code.
I have put this file into /etc/bash_completion.d, and for me it is a
useful addition, even with its currently limited functionality.

Feel free to do with the attached file whatever you want.

If you do have suggestions what to change, priority of most urgently
needed improvements, or whatever, please let me know.
(Though this is not a promise that I'll implement all suggested changes.
Everybody else is also welcome to change the script as needed.)

Should I have posted the script and continued the discussion on
john-users instead?

Frank

-------- Original Message --------
Subject: Re: [john-users] bash auto-completion for john (Was: file name
expansion for --wordlist= and file name starting with ~)
Date: Mon, 07 May 2012 19:54:37 +0200
From: magnum <john.magnum@...hmail.com>
Reply-To: john-users@...ts.openwall.com
To: john-users@...ts.openwall.com

On 05/07/2012 11:31 AM, Frank Dittrich wrote:
> Should I dig into bash auto-completion even more, to support expanding
> --wo to --wordlist= and so on?

This has been on the wiki wishlist for quite some time. But doing it
"properly" is not a one beer job.

> What other john-specific auto-completion would be useful?
> (Doing this correctly for all possible cases will probably be hard.
> Jumbo supports an extended set of options. Different shells might have
> different auto-completion mechanisms. Some distributions might already
> provide auto-completion logic for john.)

An excellent example of advanced autocompletion is git. If I write "git
checkout j" and hit tab twice, it will list branches starting with j.
Behind the scenes, it actually queried the repos in real time (and
probably caches results too).

So an ideal implementation for john IMO would be, for example, --rules=
auto-completing with a list of your currently available rules. And
--external= would auto-complete with a list of currently available
external modes/filters. From your own very john.conf, and including
sub-conf-files sourced with the .include directive... this could start
out much simpler than this but the possibilities are endless!

magnum




# bash completion for john
#
# john can either be globally installed (e.g. in /usr/bin/john),
# or it can be installed locally somewhere in a user's home directory.
# It can be an official version, or a community encanced (jumbo) version,
# with a variety of patches.
#
# Trying to build a perfect completion script will be hard.
# So let's start with a first humble attempt
# If possible, I'd like to avoid the need to maintain this script whenever
# john gets a new option.
#
# FIXME:
# 	I have pot this file into the /etc/bash_completion.d directory.
# 	A proper rollout is probably not that easy.
# 	(Of course, this file is anything but ready for a rollout to end users.) 
#
# TODO:
#       --rules= or --single= should use names of existing [List.Rules:...] sections
#       --incremental should use names of [Incremental:...] sections
#       --external should use names of [List.External:..-.] sections
#         (ust sections without a generate() function, if --wordlist, --incremental or --single
#         is present on the command line; with a generate() function, if none of these
#         options is used - WHAT IF the user adds a --wordlist option later?)
#       --rules=, --single=, --incremental=, --external= need to take into account a --config file
#         which might have been specified on the command line
#         FIXME: The user might have used -co: instead of --config..., the user might specify 
#         --config=... later (should we really scan config files for sections referenced by other
#         command line options, to skip config files which do not have the right sections?)
#         FIXME: With includes all this doesn't get easier (what if the john version which is used
#         doesn't even support these fancy additions?)
#         FIXME: To be able to locate the correct .conf and .rec files, we might even need a new
#         john option to know the values of JOHN_SYSTEMWIDE ... (e.g. --build-options)
#       --format should use supported format names for expansion
#         FIXME: older john versions used a slash as a separator
#       --restore should search for existing .rec files
#       --mkpc and other options which are not mentioned in the usage output are currently ignored
#       A lot of other options are still not considered
#       Should I support -option instead of --option?
#       Should I support --option:val, -option:val, or even -opt:val instead of just --option=val?
#

# grep and sed are used to process john's usage info
have grep && have sed && have tail &&
_john()
{
	local first cur options valopts compreplya compreplyb
	COMPREPLY=()
	_get_comp_words_by_ref -n = cur

# we need to make sure we run the correct program, not some other program 
# called john which is located somewhere in $PATH
	first="${COMP_WORDS[0]}"

	case "$cur" in
# --config= could be restricted to *.conf files (or *.ini files on Windows?),
# --pot= to *.pot files, 
# --make-charset= should probably excluded, to make overwriting existing files harder
# (otherwise it should be restricted to *.chr files)
		--wordlist=*|--config=*|--pot=*|--make-charset=*)
			cur=${cur#*=}
			_filedir
			return 0
			;;
	esac

# TODO:
#	--rules= or --single= should use names of List.Rules: sections
#	--incremental should use names of Incremental: sections
#	--external should use names of List.External: sections
#	  Just sections without generate() function, if --wordlist, --incremental or --single
#	  is present on the command line; with generate() function, if none of these
#	  options is used - WHAT IF the user adds a --wordlist option later?
#	--rules=, --single=, --incremental=, --external= need to take into account a --config file
#	  which has been specified earlier 
#	  FIXME: The user might have used -co: instead of --config..., the user might specify 
#	  --config=... later (should we really scan config files for sections referenced by other
#	  command line options?
#	  FIXME: with includes all this doesn't get easier (what if the john version which is used
#	  diesn't even support these fancy additions?)
#	  FIXME: To be able to locate the correct .conf and .rec files, we might even need a new
#	  john option (e.g. --build-options)
#	--format should use supported format names for expansion
#	  FIXME: older john versions used a slash as a separator
#	--restore should search for existing .rec files
#	--encoding should use the list of supported encodings
#	--plugin needs to expand to thge list of available plugins
#	  FIXME: how do I get that list 
#	  (to avoid the output "cannot open shared object file: No such file or directory)
#	--mkpc=COUNT and other options which are not mentioned in the usage output are currently ignored
#	  FIXME: is it save to assume --mkpc exists when other jumbo options exist, does it depend on version?
#	A lot of other options are probably still not considered
#	Should I support -option instead of --option?
#	Should I support --option:val, -option:val, or even -opt:val instead of just --option=val?
#	Or should the expansion be limited to the GNU stype --long-opt[=value]?

#	(Most options are listed at the begin of the line, but the line with the --pipe option
#	does have trailing spaces, and --stdin is mentioned after --wordlist=FILE.)
#
#	all options (the '=' will be emoved for options without a value)
	options=`$first|grep '^ *--'|sed 's#^ *\([a-z=-]*\).*$#\1#'|sed 's#--wordlist=#--wordlist=\n--stdin#'`
#       Just the options that can be used together with a value, even if that value is optional
#       (That means, for a jumbo build, --rules doesn't get a trailing space, but for the john version
#       distributed by fedora16, --rules does get a trailing space during expansion.
#       The same applies for --show)
#
	valopts=`$first|grep '^ *--[a-z\[-]*='|sed 's#^ *\([a-z=-]*\).*$#\1#'`


	if [[ ${cur} == -* ]] ; then
		compreplya=`compgen -W "${options}" -- ${cur}`
		compreplyb=`compgen -W "${valopts}" -- ${cur}`
		COMPREPLY=( $(compgen -W "${options}" -- ${cur}) )
		if [[ "_$compreplya" == "_$compreplyb" ]] ; then
#			the option has a mandatory value, so don't append a space:
			compopt -o nospace
		fi
		return 0
	else
		_filedir
		return 0
	fi
}
complete -F _john john

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ