No subject

Thu Aug 20 06:46:28 UTC 2009

Since the behaviour of COMP_WORDS has changed from bash3 to bash4
(COMP_WORDS is now split along COMP_WORDBREAKS, instead of along `shell
metacharacters'), there are times when the following common convention
produces an overlapping set:

	local cur=`_get_cword`
	local prev="${COMP_WORDS[COMP_CWORD-1]}"

This is especially true when _get_cword() is called with an optional
argument of exceptions to COMP_WORDBREAKS. For example:

	$ command subcommand --user=root:toor:<TAB>

	# in the completion function
	local cur=`_get_cword =:`
	local prev="${COMP_WORDS[COMP_CWORD-1]}"

bash3 returns:

	cur: 	--user=root:toor:
	prev: 	subcommand

while bash4 returns a less useful:

	cur:	--user=root:toor:
	prev:	toor

This patch extends both __get_cword3() and __get_cword4() to accept an
additional integer argument that specifies how many places previous to
the current word the desired word resides. It also respects any user
exceptions to COMP_WORDBREAKS.

_get_pword() is then implemented as a wrapper: `_get_cword "${@:-}" 1'


	local cur=`_get_cword =:`		=> --user=root:toor:
	local prev=`_get_pword =:`		=> subcommand

produces the same results in bash3 and bash4.


>Comment By: Freddy Vulto (fvu-guest)
Date: 2009-10-31 10:01


Thanks for the patch.  This is just what we needed for bash-4.  I changed the last `echo' in __get_cword4 to a `printf' to make completing `-n' or '-e' come through.  Declaring a function local (break_index & word_start) also doesn't work on my machine: the functions become visible global.  I considered doing an unset -f at the end of __get_cword4, but I made them global (__break_index & __word_start) because they're used so often.

See git commit: 884c3f5

Freddy Vulto


You can respond by visiting:

More information about the Bash-completion-devel mailing list