Re: compgen -C not working as I expected

[Curious Costanza]

Hey Chet,

Thank you for your response. I don't suppose that you have a small example 
handy which demonstrates a useful application of compgen with the -C or -F 
options, do you? I guess I still have the same question as the commenter who 
responded to my StackExchange post; why are -C and -F defined against compgen 
at all?

- C

On Wednesday, April 30, 2014 10:22 AM, Chet Ramey <chet.ramey@case.edu> wrote:
 
On 4/30/14, 2:49 AM, Curious Costanza wrote:

> I'm a newcomer to the bug-bash mailing list; I apologize in advance if this 
> isn't the appropriate forum for this type of question. I suspect this isn't a 
> bug, but I'm very confused about the purpose of the -C option for the compgen 
> builtin. As the warning message states, it's not working as I expected. I 
> posted a question about this to unix.stackexchange.com. Here is a link to the 
> post:
> 
> 
> http://unix.stackexchange.com/questions/117987/compgen-warning-c-option-not-working-as-i-expected/
> 
> And here is what I posted:
> 
> 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:
> 
>     -C command
> 
>         command is executed in a subshell environment, and its output is used 
>as the possible completions.

The idea is that the command is executed in a subshell, just like the
documentation says, and that whatever the command outputs is
 used as the
possible completion set.  The completions are read just like with command
substitution, using newlines as delimiters to avoid problems with other
whitespace and shell metacharacters (but allowing backslash to escape
newlines).

The calling convention is identical to the way programmable completion
calls other commands:

        $0 == cs->command       (command to execute for completion list)
        $1 == command name      (command being completed)
        $2 == word to be
 completed (possibly null)
        $3 == previous word

This is the same calling convention as shell functions used for
programmable completion, for instance.

So, your example turns into the equivalent of

$(echo \"first_option second_option\" 'compgen' 'f' '')

whose output the programmable completion code happily collects and
displays.

The command has total freedom to come up with possible completions; the
completions don't even have to share a common prefix --
 the higher-level
completion code in readline takes care of that.  Shell functions specified
with -F work the same way.

The rationale is that it allows you to use binaries or scripts written in
other languages in the same way you would use shell functions to generate
programmable completions.

It's not very useful to call this at the command prompt, since much of the
readline context is not present.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
         ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/