apt-get: long "--" option completion (e.g. --no-install-recommends) unreachable after subcommands like install/remove/purge

[AbraxasDMG]

Description

In completions/apt-get, the _apt_get() function contains two separate
completion code paths:

1. A "special subcommand" branch, entered via if [[ -v special ]]; then ... fi,
   which fires whenever a subcommand such as install, remove, purge,
   autoremove, source, build-dep, download, or changelog is found
   anywhere earlier on the command line.
2. A generic long-option branch further down:

   if [[ $cur == -* ]]; then
       COMPREPLY=($(compgen -W '--no-install-recommends --install-suggests
           --download-only --fix-broken ... ' -- "$cur"))
   fi

The problem is that the install) arm inside the "special" case block ends
with ;;& (fall-through-and-retest), so execution always continues into the
final catch-all arm:

*)
    COMPREPLY+=($(_xfunc apt-cache _apt_cache_packages))
;;

...which attempts package name completion, and the whole if [[ -v special ]]
block ends with an unconditional return.

As a result, whenever a subcommand like install is present anywhere on the
command line, the function returns before ever reaching the generic
[[ $cur == -* ]] branch further down — so long options can never be
completed after a subcommand, even though the option list clearly exists
in the script and is intended to work.

Steps to reproduce

apt-get install --no<TAB><TAB>

Expected: completion offers --no-install-recommends, --no-download,
--no-upgrade, --no-show-upgraded, etc. (all present in the hardcoded
compgen -W list later in the function).

Actual: nothing is completed. The shell instead silently attempts
_apt_cache_packages (package-name completion) against --no, which
naturally matches no package, so COMPREPLY stays empty.

This affects any apt-get subcommand handled by the special case
(install, remove, purge, autoremove, source, build-dep,
download, changelog) — i.e. exactly the subcommands people most commonly
want to pass options like --no-install-recommends, --purge,
--dry-run, etc. to.

Environment

• bash-completion version: 1:2.11-8 (also reproducible by inspection on
  upstream tags 2.9, 2.10, and 2.11)
• apt/apt-get version: 2.8.3
• OS: Linux Mint 22.3 (Cinnamon), based on Ubuntu 24.04 "noble"
• GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)

[scop]

bash-completion version: 1:2.11-8 (also reproducible by inspection on upstream tags 2.9, 2.10, and 2.11)

Just to note, 2.11 is old, from 2020. For future reference, please make sure to test with the latest version from this repo, preferably the current git main branch, as that is the only thing we support and can do something about here.

But just by quickly testing apt-get install --<TAB> with the current main branch, nothing happens, so it appears the issue is likely still present as described.

A workaround is to specify those long options before the command, I believe all of them work also when given before a subcommand, and that way they are completed. It is actually also the way the apt-get --help output specifies the placement of options and subcommands, but I agree options after commands feels more natural.

[AbraxasDMG]

Hi. Thank you very much for the quick reply. I was reporting on the version that was "up-to-date" from the aspect of the distro I am using (Linux Mint 22.3, which is based on Ubuntu 24.04). I haven't been thinking of updating only the completions for apt, considering that the version of apt itself will probably be kept at the "historically accurate" version for release 24.04 lts.

It's just that I have been using it that way since really long time ago (I don't remember from which exact release, maybe v18 lts, or even earlier). And it currently still works in 22.04 (apt v2.4.14, bash-completion v2.11-5ubuntu), even on older (not regularly updated) 24.04 (apt v2.8.3, bash-completion v2.11-8).

If I understood your response correctly, the use of commands and options in the form apt-get install --<TAB> is not something that is foreseen as a standard and desired way of using them, therefore you can freely ignore this report. I just wanted to share it, in case it was not a known regression.

[scop]

If I understood your response correctly, the use of commands and options in the form apt-get install -- is not something that is foreseen as a standard and desired way of using them

From the end of my message above:

but I agree options after commands feels more natural.