aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Chu-Carroll <>
Subject Re: Adding shorthands, defaults, and initialization files to the aurora client
Date Tue, 20 May 2014 13:37:04 GMT
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

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'?".


On Mon, May 19, 2014 at 7:51 PM, Jay Buffington <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message