Add argument interpolation inside commands

[nickthecook]

ops will append any command-line arguments to the end of the command when executing an action. For example, with this config:

Current behaviour

actions:
  say_it:
    command: echo

and this command:

ops say_it hi there

the output will be:

hi there

Problem

However, that doesn't allow for commands like this:

actions:
  scp:
    command: scp -i keys/my_private_key $1 user@host:

In this command, the user doesn't need the command-line args to ops appended to the command; it needs one of the args to be inserted at the given position, and not appended.

The variable $1 will be empty, because it is not referring to arguments to ops, but to arguments to the system shell created by Ruby, of which there are none.

Feature

~~ops could perform interpolation on the command of an action, and replace numeric variable references with the corresponding arguments to ops. If any of these replacements were made, ops could not append any of its command-line arguments to the command.~~

ops should set ENV["1"], ENV["2"], etc. and let the shell handle $*. That way, $@ also works, and any number of other shell features that depend on the arguments given.

E.g.:

actions:
  was_here:
    command: echo "$1 was here"

$ ops was_here nick
nick was here
$ ops was_here nick some_other_guy
nick was here

Note that the second time was_here was executed, two arguments were given to ops. However, since the second argument ($2) was not referenced in the command string, it was not included in the call to echo.

~~The feature could be implemented in such a way that unused arguments are appended to the command, but a use case for this isn't clear at this point. Commands that take variable numbers of arguments can use $* (see below) to append arguments not referenced directly to the command.~~

The feature should be implemented such that the shell handles $* (see Feature above).

$0

ops should set $0 to the name of the action. In the above example were_here, $0 would be set to were_here.

This could also be ops, but it seems counterintuitive to run ops one two and have $0 be ops and $1 be two.

[nickthecook]

On the subject of $*, if we take the approach of setting environment variables and letting the shell handle interpolation (which is best - see commend on #24), it would be inconsistent to treat $* as special, and only expand it to arguments that aren't otherwise referenced in the command.

I will update the description.