Feature: alias commands

[ghost]

Revised idea:

Alias support like

[aliases]
nb=new-build
js='build --ghcjs'

is probably the more universal and less complex feature to implement that would provide similar functionality.

---

Original idea:

Given that we have various commands that aren't short but typed frequently, I would welcome a feature (that we added to the Erlang build tool called rebar a couple years ago) which allows you to abbreviate the commands to run and will unabbreviate if there's a unique match, or list potential candidates otherwise:

$ rebar co b-p
will be unabbreviated to
$ rebar compile build-plt

$ rebar b
will be unabbreviated to
$ rebar build-plt

$ rebar c
ERROR: Found more than one match for abbreviated command name 'c',
please be more specific. Possible candidates:
  check-deps, check-plt, clean, compile, create, create-app, create-lib, create-node, ct

So, in cabal-install it would be:

$ cabal in
would be unabbreviated to
$ cabal install

$ cabal n-b
would be unabbreviated to
$ cabal new-build

$ cabal c
ERROR: Found more than one match for abbreviated command name 'c',
please be more specific. Possible candidates:
  configure, clean, check

[BardurArantsson]

I don't think this is a good idea unless we introduce explicit short-aliases for commands on an as-needed basis. (We should probably have per-command usage metrics to guide us even then.)

My rationales for not having it:

• It's very easy to build muscle memory for, say, "cabal in" and then somebody adds a command "cabal indent", so now suddenly it's ambiguous and your fingers have to unlearn. This can be incredibly frustrating.
• If you're using e.g. zsh as your shell you already have it. Type "cabal in[TAB]" and you're shown a little list of subcmd: info init install with appropriate formatting. If your shell's completion support doesn't do this you might want to use a better shell. Why is this better ergonomically? Because once you press [ENTER] cabal is going to do something moderately unpredictable that may not be easily reversible.
• It introduces more situations where accidentally pressing [ENTER] could do suprising things. DELETE FROM foo [accientally-presses-ENTER]... need I say more? :)

[BardurArantsson]

Oh, forgot: I do think it might be a good idea to add some sort of help-the-command-shell-expand-things type functionality such that the [TAB]-expand functionality wouldn't need to be re-implemented in each and every shell. (Unless we already have it, but I don't think so.)

Some of this stuff can be "scraped" from "cabal --help" output and "cabal foo --help" output, but that's pretty messy and error prone. Might be nicer to have a more shell-parsing-friendly format for these things.

[ezyang]

For reference, https://github.com/haskell/cabal/blob/master/cabal-install/bash-completion/cabal is our existing bash completion, maintained by @kolmodin

I think a feature like this is case of rough consensus and running code. I'm certainly not going to implement it. I think if someone submitted a patch which implemented it and didn't drastically complicate the command handling code, we should take it. Though, I am not too certain how easy this would be to do without changing our command line parsing backend. I've thus milestoned it bottom.

[ghost]

@BardurArantsson, having used this for years with rebar, I don't agree. Shell completion is not the same thing, unless it can be configured to expand without waiting for confirmation from the user. zsh's auto correction feature requires confirmation.

Accidentally running disruptive commands happens as easily with long commands or shell completion, or even mistakenly running rm * in a dir. Usually when this happens, it's due to not being 100% attentive, which I'm not sure will be avoided by longer commands, especially not when using shell command history to re-run things.

To alleviate the likelihood of users accidentally running the wrong unabbreviated command, we can make this opt-in, just like split-objects is. Alternatively, we could by default allow only safe commands to be unabbreviated and, if desired, provide a feature to selectively enable disruptive commands as well.

Another viable approach, and likely to be less controversial, is the introduction of a proper alias feature where users can define aliases. Thinking about it, aliases are useful for other cases as well, and are probably the more universal and preferable feature to implement. I've changed the ticket's title accordingly.

[aliases]
nb=new-build
js='build --ghcjs'

I like the idea of cabal aliases, not to be confused with your shell's alias support, which is different and pollutes the shell's namespace.

[BardurArantsson]

I have no objections to alias-type things. (Nor opt-in abbrev support for that matter -- except on code complexity/maintenance grounds.)

[ghost]

Alias support is probably easier (less complex) to implement and is of more universal use anyway.

[23Skidoo]

See #1089 for previous discussion.