On Fri, 26 Jun 2020 at 09:50, Jan Kratochvil <jan.kratochvil(a)redhat.com> wrote:
On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote:
> But regardless, that's something to fix in the dnf bash completion scripts,
> not a reason to completely disable completion as the earlier poster said.
TL;DR it regresses the original bash completion feature.
This will be always a catch up play. To make it working each completion script
would need to be part of the package it is implementing completion for.
Additionally it would need to be integrated into the program's commandline
parsing as otherwise it will never be 100% matching. There were efforts to
unify commandline parsing between programs but that never happened:
GNU getopt_long, glib GOption, https://en.wikipedia.org/wiki/Getopt#In_other_languages
I have shown just 'dnf' but if you really want I can find arbitrary number of
other such programs and bugs where the completion script implements things
differently than the program itself.
This is why IMHO bash-completion is only an experimental unfinished feature
and it should not be the default.
This is completely off-topic. But anyway, try sending messages over
D-Bus using dbus-send. Then try using busctl with bash-completion, and
you tell me which one you prefer. Are there some quirks and issues? Of
course. Sometimes annoying, such as the dnf example. But also
solvable, as the dnf example with ./, as someone pointed out. And
overall it's muuuch much more useful than annoying, and for some tools
you simply cannot do any useful work without it (see my initial