On Fri Aug 16, 2019 at 2:29 PM Luiz Augusto von Dentz wrote:
> Can you a description of what the changes does, perhaps a sample when
> uses in some command.
>
> > + if (!strcmp(argv[1], "help")) {
> > + for (opt = arg_table; opt && *opt; opt++) {
> > + bt_shell_printf("%s\n", *opt);
> > + }
> > + bt_shell_noninteractive_quit(EXIT_SUCCESS);
> > + return FALSE;
> > + }
I added the help option to parse_argument so that when the argument
value is "help", the result is to print a newline separated list
of the arg_table containing the other valid arguments. Now
the user gets the following output for the following commands:
$ bluetoothctl agent help
on
off
DisplayOnly
DisplayYesNo
KeyboardDisplay
KeyboardOnly
NoInputNoOutput
$ bluetoothctl advertise help
on
off
peripheral
broadcast
Only agent_arguments[] and ad_arguments[] are defined in client/main.c,
so these are effecively the only new commands. The completion script
can parse the output of `bluetoothctl agent help` and `bluetoothctl
advertise help` to complete those arguments.
Additionally, other commands now don't complain that "help" is invalid,
but otherwise have no output at all. However, I don't think there is a
need to make "help" available in more contexts.
Instead for commands that take a device (similar for controller),
I chose to parse the output of `bluetoothctl devices` to take
advantage of zsh's verbosity in completion menus. Now when completing
such commands the user can get more information than is immediately
available in the interactive shell.
e.g. I am presented with a menu with descriptions like so:
$ bluetoothctl connect <TAB>
04:52:C7:0C:D4:A7 -- Bose QuietComfort 35
40:4E:36:D9:8F:28 -- Pixel 2
A4:38:CC:20:5D:E0 -- Pro Controller
This convenient menu was my original motivation for the zsh completions,
as it makes the connect/disconnect commands much more convenient to use.
