Could autocompletions be made so that when trying to autocomplete a flag, only allowed values for it are shown?

As an example, given the following command:

commands:
- name: deploy

  args:
  - name: name
    required: true
    help: Name of the service
    repeatable: true
    allowed: [ a, b, c ]
  flags:
  - long: --stage
    short: -s
    help: Stage to manage
    arg: stage
    allowed:
      - dev
      - test
      - prod

Autocompletions will be as follows:

./cli deploy <TAB>
--help          a            test
--stage        b           prod
-h                 c
-s                 dev

Triggering autocomplete for the -s flag will result in the same autocompletions being shown:

./cli deploy -s <TAB>
--help          a            test
--stage        b           prod
-h                 c
-s                 dev

Would be clearer if:

• when autocompleting a command, show possible flags and allowed values for the positional argument
• when autocompleting a flag, show possible values for the flag only

Example: For the command:

./cli deploy <TAB>
--help          a
--stage        b
-h                 c
-s

For the flag

./cli deploy -s <TAB>
dev
test
prod

Description

I have a script I maintain that either predated nested commands, or where I missed the feature when creating it. As such, I used namespace- prefixes:

• foo-list
• foo-install
• foo-uninstall

Now that I know about nested commands, I'd like to refactor the script to use those. However, because this script is already shipped to end users, I cannot break backwards compatibility.

This is where things get interesting.

Let's say I had this:

commands:
- name: foo-list
  args:
  - name: alpha
    required: false
  flags:
  - long: --beta
  examples:
  - cli foo-list bar
  - cli foo-list bar --beta

If I then add the new command and nested command alongside this:

commands:
- name: foo-list
  help: "DEPRECATED use cli foo list"
  args:
  - name: alpha
    required: false
  flags:
  - long: --beta
  examples:
  - cli foo-list bar
  - cli foo-list bar --beta
- name: foo
  commands:
  - name: list
    args:
    - name: alpha
      required: false
    flags:
    - long: --beta
    examples:
    - cli foo list bar
    - cli foo list bar --beta

I then run into an interesting phenomenon: If I call cli foo-list --help, I do not get the "DEPRECATED use cli foo list" help message. If I reverse the order, so that the deprecated command comes last in the file, I do, but then I also get it for cli foo list --help.

(Helpfully, these both resolve to the same command script, so nothing changes in terms of actual implementation.)

I understand why this happens. Clearly, internally, bashly is normalizing the names to convert - to an underscore, and concatenates command + subcommand using an underscore, so the last definition "wins".

What would be great is if we could alias a command or subcommand to another command or subcommand.

This would not work like the current aliasing which allows providing an alternate name, usually a shorter one, for a given command. Instead, it would mean that when an alias is invoked for any reason, it would act exactly like the other command: the help/usage text would come from that command, and it would call its associated command script. The "alias" would be a name and a target only.

Such an approach would mean that my previous commands would continue to work, but users could start adopting the new syntax.

Proposal

In these examples, I'm choosing the term "target" to indicate that the given target will be executed/merged for the given command, and that no command script should be directly associated.

Behavior:

• The "target" is specified as the action that should be invoked. These are always resolved as if they were global (not from the parent command).
• If a command has a "target" element, bashly should consider any other metadata beyond the name and target to be invalid. If encountered, they should cause bashly generate to fail and bashly validate to raise an error.
• If a command has a "target" element, bashly would generate the "action" for the command such that it invokes the usage or command function associated with the target element instead, or intercept the command during parsing. (See examples below.)

Example 1: aliasing command to a subcommand

This example aliases the command "bar-list" to the nested command "foo list".

commands:
- name: foo
  commands:
  - name: list
    args:
   - name: alpha
     required: false
    flags:
    - long: --beta
    examples:
    - cli foo list bar
    - cli foo list bar --beta
- name: bar-list
  target: "foo list"

Results:

• Script src/foo_list_command.sh created.
• Script src/bar_list_command.sh NOT created.
• Calling cli bar-list --help would output the same help as cli foo list --help
• Calling cli bar-list would call whatever command script is associated with cli foo list.

In other words, when generating the production script, this could get generated:

  elif [[ $action == "bar-list" ]]; then
    if [[ ${args[--help]:-} ]]; then
      long_usage=yes
      cli_foo_list_usage
    else
      cli_foo_list_command
    fi

Alternately, the generated parse_requirements() function could match "bar-list" and set the action to "foo list" and call the "cli_foo_list_parse_requirements" function.

Example 2: aliasing command to a subcommand (normalized to same name)

This example aliases the command "foo-list" to the nested command "foo list"; doing so allows users to use "foo-list" and "foo list" interchangeably, and the usage text from "foo list" would be presented to users.

commands:
- name: foo
  commands:
  - name: list
    args:
   - name: alpha
     required: false
    flags:
    - long: --beta
    examples:
    - cli foo list bar
    - cli foo list bar --beta
- name: foo-list
  target: "foo list"

Results:

• Script src/foo_list_command.sh created.
• Calling cli foo-list --help would output the same help as cli foo list --help
• Calling cli foo-list would call whatever command script is associated with cli foo list.

This one is interesting as the normalized names for the usage and command functions would be the same. However, the point is that the non-aliased version is what would be used (not whichever comes last per current versions).

Example 3: aliasing a subcommand to a command

This example aliases the nested command "foo list" to the command "bar-list"

commands:
- name: foo
  commands:
  - name: list
    target: "bar-list"
- name: bar-list
  args:
  - name: alpha
   required: false
  flags:
  - long: --beta
  examples:
  - cli bar-list bar
  - cli bar-list bar --beta

Results:

• Script src/bar_list_command.sh created.
• Script src/voo_list_command.sh NOT created.
• Calling cli foo list --help would output the same help as cli bar-list --help
• Calling cli foo list would call whatever command script is associated with cli bar-list.

In other words, when generating the production script, this would get generated:

  elif [[ $action == "foo list" ]]; then
    if [[ ${args[--help]:-} ]]; then
      long_usage=yes
      cli_bar_list_usage
    else
      cli_bar_list_command
    fi

Alternately, the generated parse_requirements() function could match "foo list" and set the action to "bar-list" and call the "cli_bar_list_parse_requirements" function.

Example 4: aliasing a subcommand to a command (normalized to same name)

commands:
- name: foo
  commands:
  - name: list
    target: "foo-list"
- name: foo-list
  args:
  - name: alpha
   required: false
  flags:
  - long: --beta
  examples:
  - cli foo-list bar
  - cli foo-list bar --beta

Results:

• Script src/foo_list_command.sh created.
• Calling cli foo list --help would output the same help as cli foo-list --help
• Calling cli foo list would call whatever command script is associated with cli foo-list.

Example 5: aliasing a command to another command

commands:
- name: bar-list
  target: "foo-list"
- name: foo-list
  args:
  - name: alpha
   required: false
  flags:
  - long: --beta
  examples:
  - cli foo-list bar
  - cli foo-list bar --beta

Results:

• Script src/foo_list_command.sh created.
• Script src/bar_list_command.sh NOT created.
• Calling cli bar-list --help would output the same help as cli foo-list --help
• Calling cli bar-list would call whatever command script is associated with cli foo-list.

In other words, when generating the production script, this would get generated:

  elif [[ $action == "bar-list" ]]; then
    if [[ ${args[--help]:-} ]]; then
      long_usage=yes
      cli_foo_list_usage
    else
      cli_foo_list_command
    fi

I just discovered this tool, looks super cool!

I am trying to reproduce the completions example: https://github.com/DannyBen/bashly/tree/master/examples/completions but it does not seem to work.

Steps I took:

• in an empty directory, create bashly.yml
• paste the configuration from the example into that file
• Run the following commands, as per the example:

$ bashly init
$ bashly add comp function
$ bashly generate

• Run ./cli. I get the output

cli - Sample application

Usage:
  cli [command]
  cli [command] --help | -h
  cli --version | -v

Commands:
  download   Download a file
  upload     Upload a file

Note that, unlike the example, I do not have a completions command

• ./cli completions just prints the same usage information, so I can't eval that to enable completions.

bashly generated the following files:

$ tree
├── cli
└── src
    ├── bashly.yml
    ├── download_command.sh
    ├── initialize.sh
    ├── lib
    │   └── send_completions.sh
    └── upload_command.sh

2 directories, 6 files

My environment:

I am using bashly through docker, as described in the installation instructions.

$ bashly --version
0.6.4
$ bash --version
GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
$ docker image inspect dannyben/bashly
[
    {
        "Id": "sha256:82d3128ff8617e75c2e58638920f046453dd07759846b209c8bd43b0dd5f7845",
        "RepoTags": [
            "dannyben/bashly:latest"
        ],
        "RepoDigests": [
            "dannyben/bashly@sha256:bf1a326659205b5974657e76d57179ee890abf85f0fda1e960630003effb7aea"
        ],
        "Parent": "",
        "Comment": "buildkit.dockerfile.v0",
        "Created": "2021-08-27T15:24:07.059809147Z",
...

Am I doing something wrong or is this a bug?

(This overlaps with the changes in #113, but came up in an unrelated context and seemed worthy of discussion on its own merits.)

I was explicitly passing in the empty string as an argument to a flag, but bashly treated this as though the argument was absent, which is not the behavior I wanted. This PR changes that so that it will accept the empty string correctly, and adds a spec using the example of a blank password.

I think the same change should also be made to non-flag arguments, though I haven't investigated that case yet.

I haven't found such feature in the docs, but it would be awesome to have a option to show all commands & subcommands at once when using the command or help flag (or beeing able to show subcommands at parent command level by settings a option) in the bashly.yml config:

name: sample
version: 0.1.0

commands:
- name: init
- name: server
  showSubCommandsAtParentLevel: true
  commands:
  - name: setup
  - name: update
- name: app
  showSubCommandsAtParentLevel: true
  commands: 
  - name: setup
  - name: update

Executing the command could produce something like this:

Usage:
  sample [command] [subcommand]
  sample [command] [subcommand] --help | -h
  sample --version | -v

Commands:
  init        Initialize Project

  server   subcommands: 
  server   setup
  server   update

  app      subcommands: 
  app      setup
  app      update

Problem: Bashly currently wraps command script in functions and indents the code. This effectivily disables the possibility to use heredoc's. The documented suggestion is to use a script in the lib folder as this is not indented. However, this breaks again when running bashly with -w flag as everything is wrapped in a function again.

Suggestion: Use tabs to indent functions instead of spaces. This allows the use of <<-EOF heredocs which CAN be indented, but only work when text is indented with tabs instead of spaces.

Hi Danny! I was wondering if you'd be open to allowing for lib files with extensions other than *.sh.

My use case: I'm using shellcheck to validate my scripts, and I don't want to add a directive to each of the .sh files in lib/ to tell it to treat it as bash (and I don't want to force it with a command line parameter either). I'd like to just rename all the files to .bash instead.

This was easy enough to do with commands thanks to the filename directive, but there's no way around it for common functions.

Description

Not sure if this is a bug but maybe considered as one to some as it appears like this behavior is intentional and related to: https://github.com/DannyBen/bashly/issues/103

It seems that anytime other_args has - options in it, it gets split into multiple options, i.e -foo it ends up as -f -o -o

A bit more as to why this is an issue:

I have a proxy command around docker exec that proxies a command to a container, specifically to a mysql container that tries to run the mysql cli with other_args passed to it.

When passing a password to mysql cli, it's attached to the -p flag, e.g mysql -ppassword

When attempting to use other_args / catch_all, i.e mycli mysql -pexamplepassword, im ending up with something like this:

docker exec -it <my-container> mysql -u root -p -e -x -a -m -p -l -e -p -a -s -s -w -o -r -d

Which in turn causes mysql to throw an error mysql: [ERROR] mysql: unknown option '-e.

Not sure what i can do to work around this as this appears to be an intended feature per the issue linked above?

BTW, in zsh, completions doesn't work for flags. In bash, works fine. Since it is primarily targeted to bash, I am not sure if it is a bug or if an issue is needed.

Originally posted by @insign in https://github.com/DannyBen/bashly/issues/165#issuecomment-1018999898

First of all, I cannot sing the praises of bashly enough - I have been using it heavily for a BASH CLI in my project for quite some time now and it just works.

One feature that I'd like to see personally is support for allowed options for arguments. For example, a suggestion for the bashly.yml could look like:

- name: login
  short: l
  help: Log on to a cool service

  args:
  - name: role
    help: Role for user
    required: true
	allowed: ["admin", "user"]

The behaviour I am expecting is: :heavy_check_mark: login admin :heavy_check_mark: login user :x: login anythingelse - this could fail with an error message like Invalid role - allowed values are "admin" and "user"

Bash executes the script as it's reading it. When it encounters a function, it parses the function body before continuing. The bashly-generated script has all of its code in functions which appear before any code is executed (the initialize/run functions are only called at the bottom of the script). Normally this is useful, since it ensures that bash has loaded/parsed the whole script before beginning execution; however, in the case of this version check it means that if any of the functions contain syntax that Bash 3 doesn't understand, it will choke on that and crash (with a much less helpful error) before it has a chance to execute the version check:

/app/cli: line 117: conditional binary operator expected
/app/cli: line 117: syntax error near `missingno'
/app/cli: line 117: `  if [[ -v missingno ]]; then'

This PR adds a test for this situation and moves that check to the very top of the file, where it will be executed and trigger an early exit before bash tries to parse the rest of the script, so that it will work correctly regardless of the remainder of the contents.

(Extracted from #113 for clarity.)

Description

I wonder if it is possible to split bashly.yml for commands with autogenerate command.yml file.

Solution for my problems: 1.bashly.yml with multiple commands/args is huge

2.I use cookiecutter to generate project with header.yml

name: {{ cookiecutter.project_name }}
help: {{ cookiecutter.project_help }}
version: {{ cookiecutter.project_version }}

and defaults.yml with global flags

flags:
  - &force
    long: --force
    short: -f
    help: Overwrite existing files

  - &verbose
    long: --verbose
    short: -v
    help: More details

  - &debug
    long: --debug
    short: -d
    help: Debug script info

So header.yml and defaults.yml are always provided by cookiecutter/cruft across all projects and commands from files like command.yml For now I use cat or python solutions to concatenate files from bashly.d dir to bashly.yml