Modern shells, such as bash or zsh, support specifying completion through external files or scripts that the shell can parse. Having never written one, I'm not familiar with the exacts, but suffice it to say the right file in the right location with the right contents can inform the shell as to how to auto complete.
i.e., the auto-completion facilities are general / extensible.
Especially if many programs follow a general format of
program subcommand arg arg arg --optional-flag --option
(my personal favorite, as I find it most clear; followed by e.g., argparse in Python, git, many GNU utilities)
then it should be easy to see how a small specification of what subcommands take what for args or options should be enough to enable a pretty powerful auto-complete. (This is an example; I think zsh's autocompleters are actually small scripts; see https://github.com/zsh-users/zsh-completions/blob/master/zsh...)
(This, in zsh, combined with zsh's fuzzy autocomplete, is amazing.)
$ help complete
complete: complete [-abcdefgjksuv] [-pr] [-DE] [-o option] [-A action] [-G globpat] [-W wordlist] [-F function] [-C command] [-X filterpat] [-P prefix] [-S suffix] [name ...]
Specify how arguments are to be completed by Readline.
For each NAME, specify how arguments are to be completed. If no options
are supplied, existing completion specifications are printed in a way that
allows them to be reused as input.
Options:
-p print existing completion specifications in a reusable format
-r remove a completion specification for each NAME, or, if no
NAMEs are supplied, all completion specifications
-D apply the completions and actions as the default for commands
without any specific completion defined
-E apply the completions and actions to "empty" commands --
completion attempted on a blank line
When completion is attempted, the actions are applied in the order the
uppercase-letter options are listed above. The -D option takes
precedence over -E.
Exit Status:
Returns success unless an invalid option is supplied or an error occurs.
There are a lot of canned completion approaches, usually tweakable in small ways, but for heavy lifting `complete -F foo bar` will call the function `foo` when you are asking for completion of a command where the first word is `bar`. Information on what words are already on the line, where the cursor is, etc is passed in in shell variables starting with COMP_. See the "Programmable Completion" section of the bash manpage for much more detail.
Note that it's settings for a specific shell process, not global across all instances of bash. "The right file in the right location" is only relevant 1) to set up your shells a particular way by default, and 2) if the function called references a file.
Tying this back in to the earlier discussion, many distros provide standard places for installed packages to drop scripts, which will be sourced during shell startup and which can thus configure the shell appropriately each time. "Providing command line completion" for your utility, therefore, means providing any such scripts as are appropriate, and setting up your packaging (or install scripts) to install them.
i.e., the auto-completion facilities are general / extensible.
Especially if many programs follow a general format of
(my personal favorite, as I find it most clear; followed by e.g., argparse in Python, git, many GNU utilities)then it should be easy to see how a small specification of what subcommands take what for args or options should be enough to enable a pretty powerful auto-complete. (This is an example; I think zsh's autocompleters are actually small scripts; see https://github.com/zsh-users/zsh-completions/blob/master/zsh...)
(This, in zsh, combined with zsh's fuzzy autocomplete, is amazing.)