I think that bash completion is orthogonal; completions only work if the
user sets them up, and runs the correct shell. Built-in shorthands work
regardless of how the user invokes the command. Whether they're running
bash, zsh, tcsh, or esh in emacs, built-in shorthands are always available.
I definitely think that implementing completion is worth doing, but I also
think that built-in shorthands are also worthwile.
In terms of the other main objection to shorthands as I understand it: the
failure modes of shorthands are conservative, meaning that you can't use
extensions, commands, plugins, or anything else to create a situation where
adding a component causes a shorthand to resolve to something unexpected.
The "shortest unambiguous prefix" is, as these things go, very safe. Adding
things can cause a command invocation that used to work to fail, because an
addition caused something that used to be unambiguous to become ambiguous;
but the opposite is not possible. In the case that a formerly unambiguous
command becomes ambiguous due to a change, there will be a clear error
message.
For example, I recently added a new noun to the client for working with
configurations, so you can use "aurora config list" to list the jobs
configured in a config file. As things stand, you can shorten that to
"aurora c list".
I'm adding another noun for working with cron scheduler, so now there'll be
two nouns, "cron" and "config" that both start with "c". If you ran "aurora
c list", with cron added, you'd get an error message
"command prefix 'c' is ambiguous: did you mean 'config' or 'cron'?".
-Mark
On Mon, May 19, 2014 at 7:51 PM, Jay Buffington <m...@jaybuff.com> wrote:
> >
> >
> > > ## Standard Shortcuts
> > >
> > > To save typing, we'll add _automatic_ shorthand generation to
> > > the command-line framework. For nouns and verbs, any unambiguous
> > > prefix of the appropriate word will be automatically expanded to
> > > the full word.
> > >
> > > * `aurora j c` will be expanded to `aurora job create`.
> > > * `aurora con l` will be expanded to `aurora config list`.
> > >
> >
> > I'm a strong -1 against this. I don't think it saves much for the user
> and
> > I'd also be concerned how it plays with both the command plugin system
> and
> > our own ability to add commands in the future which could change how
> > prefixes are resolved.
>
>
> You can use bash completion for this (btw, zsh can parse bash completion).
>
> Implement an "aurora bash-completion" command which splits out the bash
> completion configuration. Then users (if they'd like) can put something
> like
> this in their ~/.bash_profile:
>
> complete -F `aurora bash-completion` aurora
>
> Then the user can type "aurora con<tab>" and con will get expand to config.
>
>
>
> > > ### Config Files
> > >
> > > The aurora client will look for a configuration file in the following
> > > locations, in order:
> > >
> > > 1. A file named "AuroraInit" in the current directory.
> > > 2. A file named "AuroraInit" in the sequence of parent directories
> of
> > > the
> > > current directory up to the nearest repository root.
> > > 3. A file named ".aurora" in the user's home directory.
> >
>
> I'd like to set this via a command line arg (e.g. --config), and perhaps
> even
> an environment variable (e.g. AURORA_CLIENT_CONFIG)
>
> Jay
>
