3 ms·

Can't you just parse --help in the background so we as developers don't need to write anything at all?

by Mizza 6y ago

saagarjha 6y ago
That’s not standardized at all, though.
- Mizza 6y ago
  I don't think that really matters though. I'd wager that you can write 5 or 6 simple parsers and get 99% coverage of commands used.
  - TeddyDD 6y ago
    Fish does something like this (it scans manpages) but generated completion is mostly useless in more complex cli programs (for example: kubectl, docker). So fish is shipped with a bunch of manually written completions for many commands.
    - Mizza 6y ago
      Docker looks like it would be totally doable to me. On every page, all the options are in a standardly structured "Options:" section, all commands are in a standardly structured "Commands" section, and --help and the Options: parser will also work on the subcommands. It won't have typing, but it'd work. Do the most common argument parsing libraries from the standard libraries of the most popular languages and you're mostly there. As a maintainer, I'm sick of having to include all sorts of different stupid autocompleters and think that it should be the job of an intelligent shell.
      - dastx 6y ago
        For things like docker simply parsing the help isn't enough. Docker's environment can get pretty complex, pretty quick. There are a thousand different arguments that require different kinds of inputs (think ports, mounts, images id, container I'd and much more). You cannot figure out what the argument type is from just the help or manpages. This is the case for many, many applications.
  - okdana 6y ago
    If by '99% coverage' you mean it can complete the command's options, and know which of them take arguments, and maybe even know about sub-commands, yes. zsh's _arguments, and its _gnu_generic wrapper, can do that — just compdef whatever command to _gnu_generic and it'll pull the options and descriptions out of the --help output for you. fish does something similar, and maybe bash-completion has it too, idk. But, even with relatively simple commands, that type of completion is very limited compared to the contextual functionality that proper zsh completion functions provide. These functions know... * Which arguments are meaningful to complete more than once — there's no reason to complete `-a` again after you've already entered `ls -a`, but an option like `-v` might be cumulative * Which arguments are meaningful to complete in the presence of other arguments — there's no reason to complete `-A` if you've already entered `ls -a`, since those two options are exclusive * Whether the command supports permutation — GNU tools usually do (`ls mydir/ -al`), BSD ones usually don't (`ls -al mydir/`) * Whether options can be stacked — some commands require `-a -b -c` instead of `-abc` * How options can be joined to their optargs — GNU supports both `--foo bar` and `--foo=bar`, curl supports only `--foo bar`, grep supports both `-m 3` and `-m3`, tree supports only `-L 3` * How the current argument might be affected by a previous one — if you've entered `make -C mydir` it's useful to complete targets from mydir/Makefile * How to complete multi-part arguments — if you press tab after `ssh foo@` you probably want to complete a host name or IP * The descriptions of arguments — zsh can explain what the difference between `always` and `auto` is, and even when an argument is arbitrary, it can explain what format it takes, what the default is, what the min/max are, &c. * Probably most importantly, the values of optargs and operands — just blindly offering file names or presenting a metavar parsed from --help (like WHEN or TYPE) is not very nice; a useful completion function will offer package names, man-page names, compression levels, PIDs, NIC addresses, or whatever else is appropriate I know it's technically possible to do some of this with bash completion functions, but most don't, probably because the infrastructure isn't there. fish is nicer, but even it doesn't (can't?) usually go that far with it. This level of richness (along with related UI stuff like menu selection) is why a lot of people switch to zsh even if they don't really care about its scripting features and modules and stuff. It's probably why i started using it originally. A way to specify completion behaviour declaratively would be really cool, but if it's just going to be dumbed down to bash-like functionality, i'm not sure it's going to gain much more traction with zsh users than _gnu_generic and bashcompinit (zsh's bash-completion compatibility shim) have.
- catalogia 6y ago
  Not even --help flag itself is standard, many tools only support -h, or not even that. It's truly an unfortunate and unnecessary mess.
chubot 6y ago
bash-completion already does that, and it works OK, but is limited. It's used on most Linux distros, so you've likely already used that code path. It actually invokes --help dynamically you hit `<TAB>` and parses the output dynamically. Whereas other systems do it offline in a batch job, e.g. some fish completions.

Can't you just parse --help in the background so we as developers don't need to write anything at all?

by Mizza 6y ago

Can't you just parse --help in the background so we as developers don't need to write anything at all?

saagarjha 6y ago

That’s not standardized at all, though.

Mizza 6y ago
I don't think that really matters though. I'd wager that you can write 5 or 6 simple parsers and get 99% coverage of commands used.
- TeddyDD 6y ago
  Fish does something like this (it scans manpages) but generated completion is mostly useless in more complex cli programs (for example: kubectl, docker). So fish is shipped with a bunch of manually written completions for many commands.
  - Mizza 6y ago
    Docker looks like it would be totally doable to me. On every page, all the options are in a standardly structured "Options:" section, all commands are in a standardly structured "Commands" section, and --help and the Options: parser will also work on the subcommands. It won't have typing, but it'd work. Do the most common argument parsing libraries from the standard libraries of the most popular languages and you're mostly there. As a maintainer, I'm sick of having to include all sorts of different stupid autocompleters and think that it should be the job of an intelligent shell.
    - dastx 6y ago
      For things like docker simply parsing the help isn't enough. Docker's environment can get pretty complex, pretty quick. There are a thousand different arguments that require different kinds of inputs (think ports, mounts, images id, container I'd and much more). You cannot figure out what the argument type is from just the help or manpages. This is the case for many, many applications.
- okdana 6y ago
  If by '99% coverage' you mean it can complete the command's options, and know which of them take arguments, and maybe even know about sub-commands, yes. zsh's _arguments, and its _gnu_generic wrapper, can do that — just compdef whatever command to _gnu_generic and it'll pull the options and descriptions out of the --help output for you. fish does something similar, and maybe bash-completion has it too, idk. But, even with relatively simple commands, that type of completion is very limited compared to the contextual functionality that proper zsh completion functions provide. These functions know... * Which arguments are meaningful to complete more than once — there's no reason to complete `-a` again after you've already entered `ls -a`, but an option like `-v` might be cumulative * Which arguments are meaningful to complete in the presence of other arguments — there's no reason to complete `-A` if you've already entered `ls -a`, since those two options are exclusive * Whether the command supports permutation — GNU tools usually do (`ls mydir/ -al`), BSD ones usually don't (`ls -al mydir/`) * Whether options can be stacked — some commands require `-a -b -c` instead of `-abc` * How options can be joined to their optargs — GNU supports both `--foo bar` and `--foo=bar`, curl supports only `--foo bar`, grep supports both `-m 3` and `-m3`, tree supports only `-L 3` * How the current argument might be affected by a previous one — if you've entered `make -C mydir` it's useful to complete targets from mydir/Makefile * How to complete multi-part arguments — if you press tab after `ssh foo@` you probably want to complete a host name or IP * The descriptions of arguments — zsh can explain what the difference between `always` and `auto` is, and even when an argument is arbitrary, it can explain what format it takes, what the default is, what the min/max are, &c. * Probably most importantly, the values of optargs and operands — just blindly offering file names or presenting a metavar parsed from --help (like WHEN or TYPE) is not very nice; a useful completion function will offer package names, man-page names, compression levels, PIDs, NIC addresses, or whatever else is appropriate I know it's technically possible to do some of this with bash completion functions, but most don't, probably because the infrastructure isn't there. fish is nicer, but even it doesn't (can't?) usually go that far with it. This level of richness (along with related UI stuff like menu selection) is why a lot of people switch to zsh even if they don't really care about its scripting features and modules and stuff. It's probably why i started using it originally. A way to specify completion behaviour declaratively would be really cool, but if it's just going to be dumbed down to bash-like functionality, i'm not sure it's going to gain much more traction with zsh users than _gnu_generic and bashcompinit (zsh's bash-completion compatibility shim) have.
catalogia 6y ago
Not even --help flag itself is standard, many tools only support -h, or not even that. It's truly an unfortunate and unnecessary mess.

chubot 6y ago

bash-completion already does that, and it works OK, but is limited. It's used on most Linux distros, so you've likely already used that code path. It actually invokes --help dynamically you hit `<TAB>` and parses the output dynamically. Whereas other systems do it offline in a batch job, e.g. some fish completions.