ISC bind-utils dig completion with hints helper option file for "@"

[mave007]

Summary

Adding dedicated completion for ISC BIND dig (completions-core/dig.bash), registers it in the build, adds tests, and removes dig from the generic _comp_complete_known_hosts registration in bash_completion so installed
dig.bash can take effect instead of always completing only hostnames.

Behavior (completions-core/dig.bash)

• Switch-style dig: query CLASS, RRTYPE, and NAME may appear in any order, plus +query options and @server
• One class and one type for completion purposes: after each is set (bare or via -c /-t flags) completion stops offering more classes or types. Meanwhile + options can be multiple.
• Bare ANY: classified as RRTYPE first (matches dig <NAME> ANY);
• CHAOS + TXT: suggests fixed *.bind-style names when class is CH and type is TXT.
• Query names: -q, dotted tokens, or non–class/type-prefix tokens use _comp_compgen_known_hosts where applicable.
• compopt +o bashdefault +o default to avoid broad default hostname fallback on empty COMPREPLY.
• @server: ~/.ssh/known_hosts, or BASH_COMPLETION_CMD_DIG_NS_HINTS_FILE for suffix-based hints (longest pattern wins, * defaults; trailing dots on name/pattern normalized). Format documented in comments

Example of $BASH_COMPLETION_CMD_DIG_NS_HINTS_FILE:

# Declare this in `.bashrc` as:
# export BASH_COMPLETION_CMD_DIG_NS_HINTS_FILE=<full_path_to_this_file>

# Glob useful to declare resolvers. Will match always as auto-completion
* 1.1.1.1 8.8.8.8 9.9.9.9 127.0.0.53

# Root zone and COM name servers
. a.root-servers.net. b.root-servers.net. c.root-servers.net. d.root-servers.net. e.root-servers.net. f.root-servers.net. g.root-servers.net. h.root-servers.net. i.root-servers.net. j.root-servers.net. k.root-servers.net. l.root-servers.net. m.root-servers.net.
com a.gtld-servers.net. b.gtld-servers.net. c.gtld-servers.net. d.gtld-servers.net. e.gtld-servers.net. f.gtld-servers.net. g.gtld-servers.net. h.gtld-servers.net. i.gtld-servers.net. j.gtld-servers.net. k.gtld-servers.net. l.gtld-servers.net. m.gtld-servers.net.

# Internal usage
internal.example.com 192.0.2.1 198.51.100.2 203.0.113.3

Note on removing dig from ./bash_completion

Given that dig was registered with _comp_complete_known_hosts, that generic hostname completer took precedence over the lazy-loaded completions-core/dig.bash, so dedicated completion for class, RR type, @server, and + options never ran.

The other option to avoid this case is to add into .bashrc or .bash_profile the load of the dig completion after loading bash-completion with _comp_load (example in macos with brew installation):

[[ -r "${BREWPREFIX:-/opt/homebrew}/etc/profile.d/bash_completion.sh" ]] && . "${BREWPREFIX:-/opt/homebrew}/etc/profile.d/bash_completion.sh"
_comp_load dig 2>/dev/null

Files

File	Change
completions-core/dig.bash	New dig completion
completions-core/Makefile.am	Install dig.bash
bash_completion	Stop registering dig with _comp_complete_known_hosts
test/t/test_dig.py	Integration tests
test/t/Makefile.am	Register test_dig.py

Testing

• pytest test/t/test_dig.py (cases with require_cmd=True need dig on PATH).

[scop]

Thank you for working on making bash completions better. But to verify, did you notice the two few paragraphs of CONTRIBUTING.md as linked in the PR creation view, in particular:

However, before submitting a completion to us, first consider submitting it to the project that ships the commands your completion is for.

If you considered submitting it upstream, let's include the explanation why submit it here instead. If it was asked upstream and rejected there, let's add a link to the response.

[mave007]

Still waiting for answer from current maintainer in https://gitlab.isc.org/isc-projects/bind9/-/issues/4879

I think the biggest issue we will face, is if that is uploaded on ISC end, then in this project we will still need to remove the lazy-load on bash_completion portion: https://github.com/scop/bash-completion/pull/1625/changes#diff-a4757074ff650000804fd3eaabe9b0a9e02e33040ca5b8afd4c0275fc5f3e136

If that is not done in this project, it implies the user will need to do the following on their own shell to load it after the load of bash_completion.sh:

_comp_load dig 2>/dev/null

which it's not the end of the world... but definitely not intuitive.

[akinomyoga]

I think the biggest issue we will face, is

That's not really an issue. First of all, that "issue" is not specific to dig, and a similar situation has been occurring frequently. We have been moving in-tree completion settings to fallback completions when the upstream of the corresponding commands has started to offer their completion settings themselves.

Rencently, I also thought about related changes associated with #1558 and #1339. We may move all these complete settings into separate files in completions-core or completions-fallback so that they can be customized in a way described in #1558 (comment) or #1329 (comment). Also, currently, some completion files define completion settings for multiple commands at the same time, but that may override user-defined completion settings for a command when the completion setting of another command is loaded. To avoid such a situation, the definition of the completion functions and the declaration of complete ... should also be separated when one file declares multiple complete ....