[WIP] shell completions

[miDeb]

This is a wip pr to enable tab-completions in bash, fish and zsh for all utilities. For now, I implemented this for sort.
(For convenience this is based on #2397)

How to enable completions for a utility

• Extract the clap::App creation into a different file called app.rs with a function get_app(app_name: &str) -> App
• Add a build.rs to the utility with these contents:

include!("src/app.rs");
include!("../../build_completions.rs");

• Add the dependencies needed for your app.rs file to Cargo.toml under [build-dependencies], e.g.

[build-dependencies]
clap = "2.33"

Having app.rs be a separate file reduces the amount of dependencies we have to add here, hopefully only clap is ever needed.

• That's it! Now, when building, the files necessary for completions will be generated, and when running make install, those files will be copied to the appropriate directories.

[tertsdiepraam]

Amazing! Does this work for the busybox-style executable as well or only the standalone utils?

[miDeb]

So far this only works for single utilities because afaik there is no single App for the multicall binary. We could combine the utilities as subcommands (clap subcommands can be Apps) inside of a big app. Then I think it could work

[tertsdiepraam]

Alright, thanks!

[miDeb]

I changed a bit how it works: Instead of generating the completions in build.rs, a (hidden) subcommand is added to the coreutils binary, which generates the files (e.g. cargo run completion cp bash generates the completion file for cp on bash). This makes it a bit easier IMHO, and allows to create completions for the busybox binary as well (with cargo run completion coreutils <shell>. Utilities now must have a public app module with a get_app(app_name: &str) -> App function. From my previous try I already had separated those functions into their own files called app.rs. That's not necessary anymore, these functions could now be anywhere. I could as well change the convention and move them back to their original files if that's preferred.

[miDeb]

I opened #2414 with the final (and hopefully simpler) version of this.