GNOME Bugzilla – Bug 724860
[RFE] nmcli should help bash-completion to suggest completion for `nmcli connection modify` command
Last modified: 2020-11-12 14:34:41 UTC
Bash completion for the modify command does not know enough to make good suggestions. While it would be possible to re-implement a lot of the command specific knowledge in bash itself, it is hard and would need to be maintained together with new properties in nmcli -- which already knows this information. I would request for two new options: [1] nmcli connection modify --complete [id] em1 PROP This would be called by bash completion to get a list of valid completions for connection 'em1', given a property starting with PROP. If PROP is "", it would return all supported settings (including the [+-] specifier, where appropriate). examples: $ nmcli connection modify --complete id em1 "" 802-3-ethernet.auto-negotiate 802-3-ethernet.cloned-mac-address ... ethernet.auto-negotiate ... ipv4.addresses +ipv4.addresses -ipv4.addresses ... $ nmcli connection modify --complete id em1 "eth.m" eth.method eth.may-fail [2] nmcli connection modify --complete [id] em1 PROP VALUE This would expect to resolve PROP as a valid setting of em1 and it would complete for the value "VALUE" examples: $ nmcli connection modify --complete id em1 "eth.m" "" Error: eth.m does not uniquely resolve to a valid property $ nmcli connection modify --complete id em1 "eth.me" "" auto link-local manual shared disabled $ nmcli connection modify --complete id em1 "eth.me" "a" auto $ nmcli connection modify --complete id em1 "ipv4.addr" "" <no output>
Btw. the reason, why nmcli has to do the filtering for use that we give a prefix is because it's not enough to ask nmcli which settings are supported by em1 in general. For example, if the user types nmcli connection modify em1 eth.m<TAB> we have to complete for eth.method and eth.may-fail. Thus, it is not enough, to ask nmcli what properties em1 in general has, because it would not return the proper abbreviations. eg. nmcli connection modify em1 "" gives ethernet.method ethernet.may-fail Of course, bash *could* try to figure out, that "eth.m" is an abbreviation for "ethernet.m", but nmcli can do that much easier.
There is an initial step on this on: fg/autcomplete_fix_rh1301226 here "nmcli connection modify --complete <your connection>" just returns the full list of available properties, in order to have autocompletion for 802.1x property too. Still we don't have the "eth.m" too... One easy way to do that is to change the "get_valid_autocompletion_string()" func to return all the available abbreviations... but would be a huge list, so does not seems so smart.
(In reply to Francesco Giudici from comment #2) > There is an initial step on this on: > fg/autcomplete_fix_rh1301226 > > here "nmcli connection modify --complete <your connection>" just returns the > full list of available properties, in order to have autocompletion for > 802.1x property too. patch lgtm. Where we do: if (nmc_arg_is_option (*argv, "complete")) { could we check that first, and enforce that --complete is set as first parameter after "modify" and that --temporary is not set? We don't need the flexibility to allow both for --complete and --temporary (and indeed it would be nonsensical). > Still we don't have the "eth.m" too... yeah, that can be a follow-up patch. > One easy way to do that is to change the "get_valid_autocompletion_string()" > func to return all the available abbreviations... but would be a huge list, > so does not seems so smart. hm, or... rethinking... is it really so complicated? Can you not just iterate over the arguments until you reach the last. Then you know whether the last argument is an option-name or a value. If it's an option name, isn't it quite simple to complete it with accepting abbreviations? And then you are one step away to also completing the value too. That would be awesome. Could we do the whole feature? :)
(In reply to Thomas Haller from comment #3) > <snip> > > Where we do: > if (nmc_arg_is_option (*argv, "complete")) { > could we check that first, and enforce that --complete is set as first > parameter after "modify" and that --temporary is not set? We don't need the > flexibility to allow both for --complete and --temporary (and indeed it > would be nonsensical). New branch: fg/autocomplete_fix_rh1301226_with_LR_patches Changed a bit here, merging patches from Lubo: now the --complete is a global parameter. We want to accept anyway "connection --temporary" with "--complete" because this would allow us to avoid putting any parsing in the bash-completion script and just pass all the line command to nmcli. > > > > Still we don't have the "eth.m" too... > > yeah, that can be a follow-up patch. > Sure! > > > One easy way to do that is to change the "get_valid_autocompletion_string()" > > func to return all the available abbreviations... but would be a huge list, > > so does not seems so smart. > > hm, or... rethinking... is it really so complicated? Can you not just > iterate over the arguments until you reach the last. Then you know whether > the last argument is an option-name or a value. > If it's an option name, isn't it quite simple to complete it with accepting > abbreviations? You are right > And then you are one step away to also completing the value too. > > That would be awesome. Could we do the whole feature? :) Well, completing the value would be nice :-) Last feature to add I would say ;-)
(In reply to Francesco Giudici from comment #4) > > > Still we don't have the "eth.m" too... > > > > yeah, that can be a follow-up patch. > > > > Sure! Added the property shortcut completion, updated branch: fg/autocomplete_fix_rh1301226_with_LR_patches Note: the branch fixes https://bugzilla.redhat.com/show_bug.cgi?id=1301226 so part of the code review / discussion could be found there.
Merged properties completion branch: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=68d48fa50769c34cf8f10b90788f5dca3ea60191 Still missing the autocompletion for the "values" (where applicable).
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).