Rest flags and arguments for commands

[abh1kg]

It would be nice to somehow disable the "invalid option" validation error for certain commands which can expect arbitrary options as flags and/or arguments. I am looking to develop a CLI which performs a few specific actions but ultimately delegates to the AWS CLI. Is this somehow possible?

Currently bashly.yml:

name: mycli
help: My amazing CLI utility
version: 0.1.0

commands:
- name: aws
  help: Delegators to AWS CLI
  dependencies:
  - aws
  commands:
  - name: deploy-stack
    help: |-
      Deploys a CloudFormation stack from the provided template file.
    args:
    - name: file_path
      help: Path to a file
      required: true
    - name: stack_name
      help: Name of CloudFormation stack
      required: true
    - name: template_file_path
      help: Path to CloudFormation template
      required: true

Command (which I wish it works):

mycli aws deploy-stack file1 mystack file2 --force-upload --s3-bucket mybucket

However, it exits with error:

invalid option: --force-upload

Would it be possible to relax the validation checks for a few commands?

[DannyBen]

I was contemplating the same feature for a while now, and I think I even have a branch that attempts to achieve it (but I was not happy with it).

How do you expect to obtain these args in your code? Just have a special variable (say $other_args which is an args array, similar to how "$*" would be?

[DannyBen]

Well - I have implemented it, and I think it works nicely.

• Setting catch_all: true in any command, will avoid triggering an error for additional args and flags.
• The additional args will be available under the ${other_args[@]} array in your bash code.
• The built-in inspect_args bash function will show you these additional arguments if any.

In addition, you can define the catch_all in one of these ways:

• If set to true, will just enable it and show [...] in the usage help
• If set to a string, will use that string (uppercased) in the usage help (for example command [AWS PARAMS...])
• If set to a hash containing label and help, will also show the detailed help string when using with --help (see below)

catch_all:
  label: aws params
  help: Additional parameters that will pass through to the AWS CLI

will result in:

$ ./cli download -h
mycli download - Download a file

Usage:
  cli download SOURCE [options] [AWS PARAMS...]
  cli download --help | -h
... snipped ...

Arguments:
  SOURCE
    URL to download from

  AWS PARAMS...
    Additional parameters that will pass through to the AWS CLI

Examples:

• Simple
• Advanced

---

If you can test it before I release it, it will be great.
To install the gem from github, you should create a Gemfile with this content

# Gemfile
source "https://rubygems.org"
git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }
gem "bashly", github: 'dannyben/bashly', branch: 'add/catch-all'

and then run bundle, and then bundle exec bashly generate (instead of the usual bashly generate).

[abh1kg]

@DannyBen : Thanks for the impossibly quick turnaround. I tested it with your branch and it works fine for my case!

[DannyBen]

Super. I will release a new version shortly.

Thank you for taking the time to open this issue and to test the release.

[DannyBen]

Version 0.4.3 released to Rubygems, and to Dockerhub.

[DannyBen]

@abh1kg - I have implemented something that might be of use to you.

There is now an extensible option - that provides the ability to either let your users extend the command on their own (like you can put git-anything in your path, and then running git anything will invoke it) - but more importantly for you, it is also possible to specify which is the executable you delegate to - in your example, the AWS cli.

See the Extensible Scripts section in teh README, and its associated examples if it is of any interest at all.

[JakobGM]

Hi, @DannyBen!

I'm just wondering how you would recommenced using the catch_all approach when the additional arguments are required but of unknown length? I see that providing required: true to the catch_all hash changes nothing, which makes sense.

Thanks for the great tool,

• Jakob

[DannyBen]

Hi @JakobGM - thanks for your comment. I have converted it to a new issue #96. Let me think about it for a little while, and I will post there.