Bashly - Bash CLI Framework and Generator

Overview

Bashly - Bash CLI Framework and Generator

Create feature-rich bash scripts using simple YAML configuration

Gem Version Build Status Maintainability

bashly.dannyb.co


demo

Documentation

Contributing / Support

If you experience any issue, have a question or a suggestion, or if you wish to contribute, feel free to open an issue.

Comments
  • Improve autocomplete for flag arguments

    Improve autocomplete for flag arguments

    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
    
    enhancement 
    opened by tiagoposse 32
  • Alias a command to a subcommand

    Alias a command to a subcommand

    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
    
    enhancement 
    opened by weierophinney 20
  • Bash completions do not work

    Bash completions do not work

    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?

    question 
    opened by ndepal 19
  • Allow empty string as flag argument

    Allow empty string as flag argument

    (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.

    opened by wolfgang42 17
  • Show all commands/subcommands at once and/or group/show subcommands at parent command level

    Show all commands/subcommands at once and/or group/show subcommands at parent command level

    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
    
    enhancement 
    opened by iocron 15
  • feature request: enable herdocs by indenting with tabs instead of spaces

    feature request: enable herdocs by indenting with tabs instead of spaces

    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.

    enhancement 
    opened by hojerst 15
  • Add support for loading lib files with different extensions

    Add support for loading lib files with different extensions

    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.

    enhancement 
    opened by iamjackg 14
  • Issues with `normalize_input` and `catch_all`

    Issues with `normalize_input` and `catch_all`

    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?

    bug 
    opened by surgiie 14
  • Autocompletion in ZSH

    Autocompletion in ZSH

    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

    bug 
    opened by DannyBen 14
  • [Feature] Support allowed argument values as an option

    [Feature] Support allowed argument values as an option

    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"

    enhancement 
    opened by abh1kg 14
  • Move bash 3 version check to top of file for early exit

    Move bash 3 version check to top of file for early exit

    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.)

    opened by wolfgang42 13
  • Split config file for commands

    Split config file for commands

    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

    question 
    opened by niksfirefly 1
Releases(v0.9.4)
  • v0.9.4(Dec 31, 2022)

    • Fix validate --verbose command (#321)
    • Add support for color usage elements (#322)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.9.3...v0.9.4

    Source code(tar.gz)
    Source code(zip)
  • v0.9.3(Dec 24, 2022)

    • Add support for double dash as an argument parsing terminator (#317)
    • Add bashly doc command to show reference in the terminal (#318)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.9.2...v0.9.3

    Source code(tar.gz)
    Source code(zip)
  • v0.9.2(Dec 16, 2022)

    • Fix repeatable arg validation (#312)
    • Fix all shfmt offenses (#314)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.9.1...v0.9.2

    Source code(tar.gz)
    Source code(zip)
  • v0.9.1(Dec 9, 2022)

    • Add support for default command that is used instead of showing usage (#305)
    • Remove call to root_command when there are sub-commands (#306)
    • Add the ability to choose .bash as the partials extension (#308)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.9.0...v0.9.1


    Special thanks to @iamjackg for the insightful feature ideas.

    Source code(tar.gz)
    Source code(zip)
  • v0.9.0(Dec 5, 2022)

    • Test with ruby head (#285)
    • Apply RuboCop corrections (#286)
    • Refactor rubocop rules with rentacop (#287)
    • Correct rubocop-performance offenses (#288)
    • Housekeeping with rubocop-rspec (#289)
    • Fix multiple global flags (#294)
    • Fix bash completions for commands with global flags (#297)
    • Allow command.dependencies to be a hash for custom 'how to install' messages (#298)
    • Normalize examples to include src/*.sh artifacts (#299)
    • Update approvals.bash (bashly add test) to v0.3.2 (#300)
    • Add help command library (bashly add help) (#301)
    • Improve generated script format (#302)
    • Change dependency command checker for testability (#303)
    • Add ability to define a private environment variable (#304)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.8.10...v0.9.0

    Source code(tar.gz)
    Source code(zip)
  • v0.8.10(Nov 1, 2022)

  • v0.8.9(Oct 14, 2022)

    • Add --verbose to bashly validate, to show the compiled config (#280)
    • Add command.function directive (#282)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.8.8...v0.8.9

    Source code(tar.gz)
    Source code(zip)
  • v0.8.8(Oct 8, 2022)

    • Refactor settings (internal) (#275)
    • Allow disabling compact flag expansion (-abc to -a -b -c) (#276)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.8.7...v0.8.8

    Source code(tar.gz)
    Source code(zip)
  • v0.8.7(Sep 30, 2022)

    • Update validator to alert when a default command has no args (#259)
    • Make default environment variable values available in initialize() (#268)
    • Redirect error messages to stderr (#269)
    • Add support for global command flags (#271)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.8.6...v0.8.7

    Source code(tar.gz)
    Source code(zip)
  • v0.8.6(Sep 23, 2022)

    • Fix bashly add test (#252)
    • Small Typo Fix by @DennisRippinger (#257)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.8.5...v0.8.6

    Source code(tar.gz)
    Source code(zip)
  • v0.8.5(Sep 9, 2022)

  • v0.8.4(Sep 4, 2022)

    • Update completely to version 0.5.0 (https://github.com/DannyBen/bashly/pull/248). From the completely changelog:
      • Fix shellcheck SC2162 in the generated script
      • Fix shellcheck SC2124 in the generated script
      • Hide flag completion unless input ends with a hyphen

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.8.3...v0.8.4

    Source code(tar.gz)
    Source code(zip)
  • v0.8.3(Aug 16, 2022)

    • Switch from ERB to GTX templates (https://github.com/DannyBen/bashly/pull/240)
    • Normalize templates (https://github.com/DannyBen/bashly/pull/241)
    • Show error instead of usage on invalid command call (https://github.com/DannyBen/bashly/pull/245)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.8.2...v0.8.3

    Source code(tar.gz)
    Source code(zip)
  • v0.8.2(Jun 1, 2022)

    Configuration Changes

    • Add command.expose to show subcommands in parent command's help (https://github.com/DannyBen/bashly/pull/230, https://github.com/DannyBen/bashly/pull/232, https://github.com/DannyBen/bashly/pull/236)
    • Change the command.group option so that it no longer sticky (https://github.com/DannyBen/bashly/pull/230)
      • ⚠️ Action Required: If you are using this feature, all commands that need to be under a certain group must have the group option.

    CLI Changes

    • Add --watch to the generate command (https://github.com/DannyBen/bashly/pull/237)

    Internal Changes

    • Revert (remove) CommandScopes (https://github.com/DannyBen/bashly/pull/231)
    • Fix parents revalidation issue (https://github.com/DannyBen/bashly/pull/235)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.8.1...v0.8.2

    Source code(tar.gz)
    Source code(zip)
  • v0.8.1(May 22, 2022)

    • Improve non-unique command validation by testing name and aliases together (https://github.com/DannyBen/bashly/pull/223)
    • Improve bash completion generation (https://github.com/DannyBen/bashly/pull/225)
    • Fix zsh incompatibilities by upgrading completely to 0.4.1 (https://github.com/DannyBen/bashly/pull/227)
    • Fix completions for deep command aliases (https://github.com/DannyBen/bashly/pull/228)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.8.0...v0.8.1

    Source code(tar.gz)
    Source code(zip)
  • v0.8.0(May 12, 2022)

    ⚠️ Deprecation Notice:

    The short option for command is now called alias. The short option will be supported for a while, but you should update your bashly.yml files if you are using it (see https://github.com/DannyBen/bashly/pull/220)


    • Rename Command.short to Command.alias and add support for multiple values https://github.com/DannyBen/bashly/pull/220
    • Add deprecation warning for command.short https://github.com/DannyBen/bashly/pull/221
    • Validate uniqueness of command args, flags and subcommands https://github.com/DannyBen/bashly/pull/222

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.7.10...v0.8.0

    Source code(tar.gz)
    Source code(zip)
  • v0.7.10(Apr 29, 2022)

    Changes

    • Disallow catch_all together with repeatable arg (https://github.com/DannyBen/bashly/pull/209)
    • Add support for generating tab-indented scripts using BASHLY_TAB_INDENT (https://github.com/DannyBen/bashly/pull/217)
    • Add settings.yml as an alternative to environment variables (https://github.com/DannyBen/bashly/pull/218)
    • Support env value in settings.yml as an alternative to BASHLY_ENV (https://github.com/DannyBen/bashly/pull/219)

    Internal Refactoring

    • Refactor parse_requirements views (https://github.com/DannyBen/bashly/pull/212)
    • Refactor flag case view (https://github.com/DannyBen/bashly/pull/213)
    • Add some specs for improved branch-level coverage (https://github.com/DannyBen/bashly/pull/214)
    • Reduce cognitive complexity in Command#load_user_file (https://github.com/DannyBen/bashly/pull/215)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.7.9...v0.7.10

    Source code(tar.gz)
    Source code(zip)
  • v0.7.9(Apr 2, 2022)

    • Add support for repeatable args https://github.com/DannyBen/bashly/pull/202
    • Abort generation if the config file contains unknown keys https://github.com/DannyBen/bashly/pull/205
    • Allow generating script without file marker comments https://github.com/DannyBen/bashly/pull/206
    • Add a help footer when running bashly without arguments https://github.com/DannyBen/bashly/pull/207

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.7.8...v0.7.9

    Source code(tar.gz)
    Source code(zip)
  • v0.7.8(Mar 11, 2022)

    • Remove --version from subcommands https://github.com/DannyBen/bashly/pull/198

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.7.7...v0.7.8

    Source code(tar.gz)
    Source code(zip)
  • v0.7.7(Feb 20, 2022)

    • Add bashly version to generated script header comment (https://github.com/DannyBen/bashly/pull/190)
    • Fix whitelist filter on repeatable flags (https://github.com/DannyBen/bashly/pull/191)
    • Add BASHLY_LIB_DIR configuration variable (https://github.com/DannyBen/bashly/pull/193)
    • Add more friendly errors on invalid configuration (https://github.com/DannyBen/bashly/pull/194)
    • Ruby 3.1 adjustments (https://github.com/DannyBen/bashly/pull/195)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.7.6...v0.7.7

    Source code(tar.gz)
    Source code(zip)
  • v0.7.6(Feb 18, 2022)

    • Add support for repeatable flags (https://github.com/DannyBen/bashly/pull/180)
    • Make args array available in user filters (https://github.com/DannyBen/bashly/pull/182)
    • Add support for exclusive flags (conflicts) (https://github.com/DannyBen/bashly/pull/182)
    • Add approvals.bash testing library (https://github.com/DannyBen/bashly/pull/183)

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.7.5...v0.7.6

    Source code(tar.gz)
    Source code(zip)
  • v0.7.5(Feb 14, 2022)

  • v0.7.4(Feb 13, 2022)

  • v0.7.3(Feb 3, 2022)

    • Allow specifying filenames for command partials
    • Add validations for flag and arg names

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.7.2...v0.7.3

    Source code(tar.gz)
    Source code(zip)
  • v0.7.2(Jan 28, 2022)

    • Add support for stdin
    • Refactor catch_all (internal)
    • Refactor command scopes
    • Fix autocomplete in ZSH

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.7.1...v0.7.2

    Source code(tar.gz)
    Source code(zip)
  • v0.7.1(Nov 17, 2021)

    • Refactor library handling (internal)
    • Make generated scripts compatible with bash strict mode
    • Add support for private commands
    • Add ability to import external snippets in bashly.yml
    • Validate the entire config prior to generating
    • Add bashly validate CLI command

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.7.0...v0.7.1

    Source code(tar.gz)
    Source code(zip)
  • v0.7.0(Oct 29, 2021)

    Highlights

    • Allow required args to appear after flags
    • Refactor library functions (internal)
    • Auto upgrade libraries when running bashly generate --upgrade
    • Add support for ## hidden comments

    Merged Pull Requests

    • Allow required args to appear after flags by @DannyBen in https://github.com/DannyBen/bashly/pull/139
    • Refactor fixture approvals by @DannyBen in https://github.com/DannyBen/bashly/pull/140
    • Remove unnecessary test files by @DannyBen in https://github.com/DannyBen/bashly/pull/141
    • Refactor Models to Script by @DannyBen in https://github.com/DannyBen/bashly/pull/142
    • Refactor library functions by @DannyBen in https://github.com/DannyBen/bashly/pull/143
    • Auto upgrade libraries by @DannyBen in https://github.com/DannyBen/bashly/pull/144
    • Add support for hidden comments by @DannyBen in https://github.com/DannyBen/bashly/pull/146

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.6.9...v0.7.0

    Source code(tar.gz)
    Source code(zip)
  • v0.6.9(Oct 26, 2021)

    • Add optional arg/flag validation functions
    • Automatically add allowed arguments to completions
    • Add more custom validations
    • Add support for NO_COLORS

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.6.8...v0.6.9

    Source code(tar.gz)
    Source code(zip)
  • v0.6.8(Oct 12, 2021)

    • Add --quiet to bashly generate
    • Fix --wrap func generation excess newlines
    • Add support for a custom script header
    • Improve friendly error on bash 3

    Full Changelog: https://github.com/DannyBen/bashly/compare/v0.6.7...v0.6.8

    Source code(tar.gz)
    Source code(zip)
  • v0.6.7(Sep 27, 2021)

Owner
Danny Ben Shitrit
Danny Ben Shitrit
GPT-3 powered CLI tool to help you remember bash commands.

Rusty: GPT-3 Powered CLI Tool Convert natural language into executable commands directly from the terminal! Open source CLI tool powered by OpenAI (br

Zahid Khawaja 287 Apr 19, 2023
Simple joke randomizer from bash.org.pl made as CLI Tool in Rust.

RBashOrg Simple joke randomizer from bash.org.pl made as CLI Tool in Rust. Description Main motivation of this project was to learn basic concepts abo

Krzysztof Szostak 3 Feb 20, 2024
Use Git installed in Bash on Windows/Windows Subsystem for Linux (WSL) from Windows and Visual Studio Code (VSCode)

WSLGit This project provides a small executable that forwards all arguments to git running inside Bash on Windows/Windows Subsystem for Linux (WSL). T

A. R. S. 1.1k Jan 3, 2023
A `nix` and `nix-shell` wrapper for shells other than `bash`

nix-your-shell A nix and nix-shell wrapper for shells other than bash. nix develop and nix-shell use bash as the default shell, so nix-your-shell prin

Mercury 15 Apr 10, 2023
Nvm - Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions

Node Version Manager Table of Contents Intro About Installing and Updating Install & Update Script Additional Notes Troubleshooting on Linux Troublesh

nvm.sh 63.8k Jan 7, 2023
An enhanced history(1) for bash

history This is a replacement for the history builtin in bash. It has a couple of additional features that relative to the one included with bash: Con

Robert T. McGibbon 4 Aug 25, 2022
Check if the process is running inside Windows Subsystem for Linux (Bash on Windows)

is-wsl Check if the process is running inside Windows Subsystem for Linux (Bash on Windows) Inspired by sindresorhus/is-wsl and made for Rust lang. Ca

Sean Larkin 6 Jan 31, 2023
A CLI-based pride flag generator written in Rust

?? prideful (in development) A CLI-based pride flag generator written in Rust. How to run Build the project using cargo. Install cargo by following th

Angelo-F 35 Sep 3, 2022
A secure CLI password generator written in rust.

Rust CLI Password Generator Overview This Project is a secure CLI password generator written in rust. This generates a secure password with three diff

pouyan shalbafan 12 Nov 9, 2023
Blazingly fast interpolated LUT generator and applicator for arbitrary and popular color palettes.

lutgen-rs A blazingly fast interpolated LUT generator and applicator for arbitrary and popular color palettes. Theme any image to your dekstop colorsc

null 12 Jun 16, 2023
CarLI is a framework for creating single-command and multi-command CLI applications in Rust

CarLI is a framework for creating single-command and multi-command CLI applications in Rust. The framework provides error and IO types better suited for the command line environment, especially in cases where unit testing is needed.

Kevin Herrera 3 Jan 21, 2022
Interface definition generator and standard for Move packages.

Move IDL Interface definition generator and standard for Move packages. Documentation is currently extremely sparse but will be improved in the near f

The Moving Company 10 Aug 25, 2022
A simple, fast, and easy to use Solidity test generator based on the Branching Tree Technique.

bulloak A simple, fast, and easy to use Solidity test generator based on the Branching Tree Technique. Installing cargo install bulloak Usage Basic Us

Alexander González 38 Aug 7, 2023
Shiva library: Implementation in Rust of a parser and generator for documents of any type

Shiva Shiva library: Implementation in Rust of a parser and generator for documents of any type Features Common Document Model (CDM) for all document

Igumnoff Software 149 Jul 25, 2024
A minimal CLI framework written in Rust

seahorse A minimal CLI framework written in Rust Features Easy to use No dependencies Typed flags(Bool, String, Int, Float) Documentation Here Usage T

Keisuke Toyota 223 Dec 30, 2022
CLI toolkit for GTD framework.

GTDF_Crabby CLI toolkit for GTD framework. How to use crabby 0. Parameters Crabby is a CLI toolkit and gets parameters as input. All the main options

akrck02 2 Feb 13, 2022
A small cli demo of rust&wasm hostcall framework.

A Cli Example for Rust and WebAssembly Hostcall Usage # build wasms for ervery module in the `wasm` directory and move them to the root directory # ex

BC2022 3 Aug 29, 2022
Yet another fractal generator (based on glium)

Juliabrot Yet another fractal generator. Juliabrot is a Rust application using the OpenGL Framework to render in realtime. Install Rust To download Ru

Max 2 Feb 27, 2022