I'm failing to get complete to offer full suggestions when the options in ${COMPREPLY[@]} contain a : character. Instead, it only offers the prefix that is common to all suggestions. Here's an example that works fine:

_foo()
{
  local cur=${COMP_WORDS[$COMP_CWORD]}
  COMPREPLY=( $(compgen -W "bart baze" -- "$cur" ) )
}
complete -F _foo foo

And here's how it is used (I never press Enter, only TAB where indicated)

$ foo 
$ foo ba       
bart baze      
$ foo bart     
$ foo h:ba         
$ foo h:ba         <-- No effect

[The manual](https://www.gnu.org/software/bash/manual/html_node/Programmable-Completion-Builtins.html) suggests something about -I working with delimiters, but complete -I -F _foo foo doesn't change anything. --- If I inspect deeper, it seems to be with how complete -F interprets ${COMPREPLY[@]}. compgen seems to set COMPREPLY just fine.

$ COMPREPLY=( $(compgen -W "h:bart h:baze" -- h) )
$ for i in "${COMPREPLY[@]}"; do echo "$i"; done
h:bart
h:baze

I am in the process of replicating my development environment under Ubuntu from Macos. A good deal of which consists of porting some utility zsh scripts *from one machine to the other*. One recurring hurdle has been getting compgen to work. I've researched posts like [Bash completion does not work in ZSH/Oh-My-ZSH because COMP_WORDS is not an array](https://stackoverflow.com/questions/69675174/bash-completion-does-not-work-in-zsh-oh-my-zsh-because-comp-words-is-not-an-arra) Bottom line: so far, on Linux zsh, I am stuck with "compgen command not found". I did use locate to find a compgen somewhere under bash completions, but calling it from zsh did not work. Yes, compgen works, from bash. Back on my mac, where compgen does work, I idly did a which compgen under zsh, which returned what looks like a function definition rather than a path. which compgen : (only first 10 lines copied to give you an idea)

`
compgen () {
	local opts prefix suffix job OPTARG OPTIND ret=1 
	local -a name res results jids
	local -A shortopts
	emulate -L sh
	setopt kshglob noshglob braceexpand nokshautoload
	shortopts=(a alias b builtin c command d directory e export f file g group j job k keyword u user v variable) 
	while getopts "o:A:G:C:F:P:S:W:X:abcdefgjkuv" name
	do
		case $name in
....

` Meanwhile, under **bash**, which compgen returns nothing, presumably because it is a builtin. So where does compgen under **zsh** come from? Is it computed through the completion initialization in my **~/.zshrc** ? quite possibly bashcompinit?: (note: below is from the macos ~/.zshrc, where compgen works)

`
# The following lines were added by compinstall
zstyle :compinstall filename '/Users/me/.zshrc'
autoload -Uz compinit
compinit
# End of lines added by compinstallx

autoload -Uz bashcompinit
bashcompinit

#stop completions from $PATH on source, as per https://stackoverflow.com/a/72710684 
unset '_comps[source]'

`

Is there a command to get builtin commands on zsh? For example, it is possible to get all builtin commands with the compgen -b command in the bash shell.

There are many resources available (1 , 2 , 3 ) that explain how to make use of bash's ability to auto-complete commands and arguments, but all of these resources require the addition of code to a user's ~/.bash_profile or /etc/bash_completion.d/* but is there a way to make a script and its available completions self-contained? As a crude and _incomplete_ example: **~/bin/script-with-integrated-autocomplete.sh**:

#!/usr/bin/env bash

function _completions {
  complete ...
}

if [ "$1" == "completions" ]; then
  _completions
  exit 0
fi

# (Whatever the script really does goes here.)
# ...
# ...

The deal-breaker (in the context of this question) is that the above example still requires you to add something like ~/bin/script-with-integrated-autocomplete.sh completions to your .profile to engage the completions. **Is there a way for a single bash script (file) to declare its own completions and have bash recognize them _at the time of invocation_ (ideally with no additional system or environment setup)?**

From help compgen: $ help compgen compgen: compgen [-abcdefgjksuv] [-o option] [-A action] [-G globpat] [-W wordlist] [-F function] [-C command] [-X filterpat] [-P prefix] [-S suffix] [word] Display possible completions depending on the options. Intended to be used from within a shell function generating possible completions. If the optional WORD argument is supplied, matches against WORD are generated. Exit Status: Returns success unless an invalid option is supplied or an error occurs. **What do options [-abcdefgjksuv] stand for?** In other words, I want to know how to use all options.

I ran into a situation where I was piping the output of compgen -G to xargs basename and could not get it to work until I added the xargs -I parameter as seen below. Here is a script demonstrating what I was trying to do, with explanatory comments. I have two questions, and they appear after the script.

# create three files for testing:
touch /tmp/my.file.1.2.txt
touch /tmp/1.my.file.2.txt
touch /tmp/1.2.my.file.txt

# create a glob and verify that it works with compgen:
glob=/tmp/*.file*.txt
compgen -G "$glob"

#output:
/tmp/1.2.my.file.txt
/tmp/1.my.file.2.txt
/tmp/my.file.1.2.txt

# try to get the basename of each file using xargs.
# I thought this would work, but it does not.
compgen -G "$glob" | xargs basename

#output:
basename: extra operand ‘/tmp/my.file.1.2.txt’
Try 'basename --help' for more information.

# eventually I discovered that this would work.
# however, I don't understand why this would work
# but the previous attempt would not, since I
# think that this command is just a more
# explicitly-specified version of the previous 
# one.
compgen -G "$glob" | xargs -I{} basename {}

#output:
1.2.my.file.txt
1.my.file.2.txt
my.file.1.2.txt

Other commands work with xargs without the -I parameter. For example, compgen -G "$glob" | xargs ls -al works just fine. Question 1: What is it about basename in this script that requires the -I parameter? Question 2: Until observing this result, I would have thought that xargs basename and xargs -I{} basename {} were synonyms of each other, but obviously they are not. What is the difference? I doubt that it matters, but just in case: this is occurring on bash 5.0.17(1)-release running on Ubuntu 20.04.4 (5.13.0-35-generic). I know there are other ways to generate this list of files, but I am concerned because I am clearly not understanding something fundamental here that I need to understand in order to avoid errors in the future.

What is the correct way to use the compgen -C option? I'm trying to learn about Bash programmable completion, and in particular the compgen builtin function. I'm experimenting with the different compgen command-line options, and I don't understand how the -C flag is supposed to work. From the [GNU Bash Reference Manual](http://www.gnu.org/software/bash/manual/html_node/Programmable-Completion-Builtins.html) : > -C command > >> command is executed in a subshell environment, and its output is used as the possible completions. Based on this, I expect something like the following to work: $ compgen -C 'echo "first_option second_option"' f first_option But instead, I get this: $ compgen -C 'echo "first_option second_option"' f -bash: compgen: warning: -C option may not work as you expect first_option second_option f I've tried this with Bash version 4.2.45 on OS X 10.7 and with Bash version 4.2.25 on Ubuntu 12.04, and in both cases I get the same error: -bash: compgen: warning: -C option may not work as you expect

I'm trying to create a command completion function, and I was following this guide . This is approximately how it looks:

function __my_completion ()
{
	local cur prev opts opts_log opts_import
	COMPREPLY=()
	cur="${COMP_WORDS[COMP_CWORD]}"
	prev="${COMP_WORDS[COMP_CWORD-1]}"
	opts="-h --help -d --directory -v --version -l --log-level -q --quiet"
	opts_log="trace debug info warn err critical off"

	if [[ ${cur} == -* || ${COMP_CWORD} -eq 1 ]] ; then
		COMPREPLY=( $(compgen -o nospace -d -W "${opts}" -- ${cur}) )
		return 0
	fi
	case "${prev}" in
		-d|--directory)
			COMPREPLY=( $(compgen -o nospace -d ${cur}) )
		;;
		-l|--log-level)
			COMPREPLY=( $(compgen -W "${opts_log}" -- ${cur}) )
		;;
	esac
}

complete -F __my_completion myProg

My problem is: whenever any word is completed, a space is added to the end. That's fine for normal options, but it's also done with directories, despite the -o nospace -d option combination. That is very annoying, as it slows down navigation and is very unintuitive. Why is that and how can I correct it? Also, while I'm here, what's the single ? for in one of the examples in the linked guide? It's in the line

COMPREPLY=( $(compgen -f ? ${cur}) )

I have two folders under /tmp. **From terminal:**

ls -d /tmp/firefox-*

/tmp/firefox-sy2vakcj.default-esr-charlie-cache
/tmp/firefox-sy2vakcj.default-esr-charlie-profile

or

compgen -G /tmp/firefox-*

/tmp/firefox-sy2vakcj.default-esr-charlie-cache
/tmp/firefox-sy2vakcj.default-esr-charlie-profile

And i can store the output in an array as well:

arr=( $(ls -d /tmp/firefox-*) )
echo $arr
tmp/firefox-sy2vakcj.default-esr-charlie-cache  /tmp/firefox-sy2vakcj.default-esr-charlie-profile
 
echo $arr 
tmp/firefox-sy2vakcj.default-esr-charlie-cache

echo $arr
/tmp/firefox-sy2vakcj.default-esr-charlie-profile

so far so good. But if i attempt the same thing from a script:

...
    ... 
    arr=( "$(ls -d /tmp/firefox-*)" ) ||( echo "directory doesn't exist" && exit 1)
    #arr=( "$(compgen -G /tmp/firefox-*)" ) ||( echo "directory doesn't exist" && exit 1)
    echo "this is a test for arr: $arr"
    echo "this is a test for arr: $arr"
    ...

I get the output: **From script:** for

-d

this is the output:

+ arr=("$(ls -d /tmp/firefox-*)")
++ ls -d '/tmp/firefox-*'
ls: cannot access '/tmp/firefox-*': No such file or directory
+ echo 'directory doesn'\''t exist'
directory doesn't exist

and for

-G

, this is the output:

this is a test for arr: /tmp/firefox-sy2vakcj.default-esr-charlie-cache
/tmp/firefox-sy2vakcj.default-esr-charlie-profile
this is a test for arr: /tmp/firefox-sy2vakcj.default-esr-charlie-cache
/tmp/firefox-sy2vakcj.default-esr-charlie-profile

**My questions:** **1.** Why is the glob not expanding in the subshell for the command

-d

? **2.** With

-G

, how are the values being stored in the array? the output seems like each entry in the array is storing both the directory entry with the second one with its own index array? **3.** Is the output from terminal for both commands different from the script, or am i missing something?

I expected that

compgen -A file -G './tmp/*.sh'

would show only files under tmp/, but it also showed all files in the current directory. I have tried

compgen -A file -X  '!(tmp/*.sh)'

and

compgen -A file -X  "!(tmp/*.sh)"

but both result in null output. Checking settings:

$ shopt|grep extglob
extglob        	on

It's also worth noting that

compgen -A file tmp/*.sh

returns only the first valid candidate. Incidentally, this exactly matches the default line completion result, e.g.

cp tmp/*.sh[TAB]

and

ls tmp/*.sh[TAB]

both expand out to only the first candidate. Two questions: 1. Why? 2. Any way to get the expected result using only compgen? The 'expected result' is for all the matching candidates to be returned, as would happen with ls tmp/*.sh

I happen to be on *Ubuntu 18.04*, with *GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)* The output of

% compgen -A file --
test-data
foobar
--

outputs all files/dirs in the current directory as though no token to complete was passed. However, the call

% compgen -A file -- --
--

correctly outputs either nothing or --* depending upon whether or not there is actually a file/files --\* present. (NOTE: Trying pass '--' using the '-W' parameter doesn't help. The relevant [gnu man page](https://www.gnu.org/software/bash/manual/html_node/Programmable-Completion-Builtins.html) and [ubuntu man page](http://manpages.ubuntu.com/manpages/xenial/man1/bash.1.html) are identical - > compgen [option] [word] > > Generate possible completion matches for word according to the options, which maybe any option accepted by the complete builtin with the exception of -p and -r, and write the matches to the standard output. When using the -F or -C options, the various shell variables set by the programmable completion facilities, while available, will not have useful values. > > The matches will be generated in the same way as if the programmable completion code had generated them directly from a completion specification with the same flags. If word is specified, only those completions matching word will be displayed. > > The return value is true unless an invalid option is supplied, or no matches were generated. It appears as though the -- parameter works as an optional delimiter to show where the partial begins, but it is also interpreted as an 'illegal option` with regards to the return status. It's easy enough to put in the extra -- to work as a delimiter so that -- is interpreted correctly, but can I rely on the -- to always be required across different bash versions and/or linux (or unix) systems?

I have a simple bash completion script that essentially invokes my (non-bash) program and set its output to COMREPLY, i.e.

COMPREPLY=( $(my-program -- "${COMP_WORDS[@]}") )

Some of the options accept comma separated value, is there a way to handle suggestion only for the last item? Let's say the user types -v opt1,opt2,o, let's say my program finds out the the valid options at this point are opt3 or opt4. If I just return those 2 and press TAB the output changes to just o (entire prefix gone). It works if I return opt1,opt2,opt3 and opt1,opt2,opt4, but that doesn't look nice. Possible solution is to do something like https://unix.stackexchange.com/questions/124539/bash-completion-for-comma-separated-values , that is, invoke my-program to generate [opt3, opt4], and pass that as word list to compgen with opt1,opt2, as prefix. But that requires duplicating some logic in the bash script as in my-program . Is there a better way?

I have an app, browser shell and I'm executing this command to get list of execuables (https://unix.stackexchange.com/questions/120786/list-all-binaries-from-path/261971) compgen -A function -abck | sort | uniq and when I call this command It return executables but I've got lot of errors from SELinux like this one: SELinux is preventing bash from getattr access on the file /usr/sbin/chronyd. allow this access for now by executing: # ausearch -c 'bash' --raw | audit2allow -M my-bash # semodule -X 300 -i my-bash.pp is there a way to prevent that that error? I want my app to work in SELinux as well without any errors out of the box. I can change PATH or execute some command to check if path can be in PATH variable, which probably /usr/sbin can't be in PATH. Does such command exists? I have this PATH by default: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/games this is the result of sudo ausearch -c 'bash' --raw type=AVC msg=audit(1506851274.781:2921): avc: denied { getattr } for pid=12298 comm="bash" path="/usr/sbin/xl2tpd" dev="sda1" ino=2239132 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:l2tpd_exec_t:s0 tclass=file permissive=1 and with | audit2why: type=AVC msg=audit(1506851274.781:2921): avc: denied { getattr } for pid=12298 comm="bash" path="/usr/sbin/xl2tpd" dev="sda1" ino=2239132 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:l2tpd_exec_t:s0 tclass=file permissive=1 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. is it possible to make my code work wihout the audit2allow?

I'm building an alternative to readline and would like to have tab completion in a similar way to how readline has tab completion. In readline, if you type git you get all the git subcommands as autocomplete options. But if you type ls you get files and directories. It's pretty clear how to get those individually by invoking compgen using one of it's options, but it's not clear how to invoke compgen and get the same set of completions that readline gives. Essentially completeing from all applicable sources. What option can I supply to get that behaviour?

Suppose I have a bash function specialcat that cats a file in the ~/Special directory specialcat () { cat ~/Special/$1 } Suppose the ~/Special directory was set up like so: mkdir ~/Special echo This is the first special file > ~/Special/firstfile echo This is the second special file > ~/Special/secondfile The specialcat function is used like: > specialcat firstfile This is the first special file I want to enable argument completion so that > specialcat firstf[TAB] produces > specialcat firstfile regardless of what the current working directory is and what files happen to be there. This is my attempt so far _options_specialcat () { COMPREPLY=( $(compgen -W "$(ls ~/Special)") ) } complete -F _options_specialcat specialcat which leads to > specialcat firstf[TAB] firstfile secondfile > specialcat firstf That is, pressing tab on a partial file name will display the list of files, but will not complete the command. How do I alter my _options_specialcat function to produce the desired behavior?

Some of the git commands have many options, and it would often be useful to search through them for the one I need - I was just looking for the option which controls the TAB width in git-gui, but there are about 200 completions for git config. An obvious workaround is to copy all the completions into an editor and search through them, but I'd rather do [something] | grep tab There are no man or info pages for compgen, help compgen doesn't even explain its own options, and there's no auto-complete for compgen (how's that for irony?). PS: compgen -A doesn't work. PPS: This is not a question about git-gui - The solution to the tab width question was elsewhere. PPPS: This is *not* about auto-completing commands, only *command parameters*.

As part of a larger autocomplete function I'm writing, I want to use compgen to generate a list of files. I read the bash manual entries for compgen and complete, and from there I assumed that the option -G "*" would be the solution. I could not get it to work, though: The list of files in the current directory was shown, regardless of my input, i.e.: $ cmd aa bb cc $ cmd a aa bb cc $ cmd aa aa bb cc Therefore, I tried to debug this by using complete, which supports the same options as compgen, but I got the same result: $ complete -G "*" cmd $ cmd a aa bb cc I also tried complete -o filenames, but this doesn't work either..