guardam / slap Goto Github PK

I might be me, but I conldn't solve this one by myself...

Using Slap 1.2.0 On Ubuntu 12.04.
Given the following test.sh script:

#!/bin/bash

# shellcheck disable=SC2154

eval "$(slap parse bash _ -- "$@" <<-EOF
name: test

args:
    - path:
        help: "Where to search"
        long: path
        short: p
        default_value: "."

subcommands:
  - add_field:
      about: Add a new field below a given one
      args:              
          - below:
              help: "The name of the field below which the new field is to be inserted."
              long: below
              takes_value: true
              required: true
              allow_hyphen_values: false
          - name:
              help: "The name of the new field"
              index: 1
              allow_hyphen_values: false
EOF
)"; [[ -z "${_success}" ]] && exit 1


if [ "${_subcommand}" == "add_field" ]; then
    printf "TEST: _add_field_below_vals=%s\n" "${_add_field_below_vals}"
    printf "TEST: _add_field_name_vals=%s\n" "${_add_field_name_vals}"
fi

Invoking it via ./test.sh -p path add_field "newfield" --below="oldfield" gives

TEST: _add_field_below_vals=oldfield
TEST: _add_field_name_vals=(newfield)_path_occurs=1

instead of the expected

TEST: _add_field_below_vals=oldfield
TEST: _add_field_name_vals=newfield

#8

For example:

• https://github.com/BurntSushi/ripgrep/blob/master/complete/_rg
• https://github.com/sharkdp/fd/blob/master/contrib/completion/_fd

This would be a really important feature.
We should support a POSIX sh target to extend compatibility with all the POSIX compliant shells.

Hi,
there are enough examples to get started with Slap, but I'm left with unanswered questions about how the variables are named.

Take the first example, with an argument named username:
why is the associated variable named _username_vals rather than username ?
Are there any benefits for the extra _...._vals ?
Are these benefits worth the loss in readability ?
Does the leading underscore mean that _username_vals shouldn't be used directly ? If so, why ?

Cheers, and thanks for your work !

At my job, we occasionally write bash scripts. Argument parsing and dependency checking is awful, but slap looks it would inject some sanity into that process. Typically, there's a small number of people that write scripts and many more that would execute the scripts. Using cargo as slap's installation method makes it seem like slap would cause more problems for people who support the script than it solves if we need everyone to

1. Install rustup.
2. Install slap with cargo.
3. Update slap and rust occasionally.

That is, it seems like we'd gain some sanity the few times we set up argument parsing, help text, etc in scripts, but lose more than that as we debug coworkers installing and updating rustup. Maybe I'm overestimating how much work that would be.

Is it realistic to start providing binaries slap here? Then we could provide instructions like "download slap from __ and put it in $PATH" and skip rustup/cargo.

In this project it's easy to have subtle logic errors. We should have some tests to make the releases more robust.

In 12cd8cb , the README.md says [clap](#clap) in a few places but that is incorrect. The correct link is [clap]: https://github.com/clap-rs/clap, which is already used in the README.md at one place.

Do you plan to publish this to crates.io? Unfortunately, the name slap is already taken there so you would have to rename.

#8

Running ShellCheck against a "slapped" script produces one warning per variable ; for instance:

)"; [[ -z "${_success}" ]] && exit 1
           ^---------^ SC2154: _success is referenced but not assigned.

How could we silent ShellCheck when using Slap ?
The only way I could think of is to add

# shellcheck disable=SC2154

below the shebang ; but doing so will prevent further errors with non-slap variables from being reported.

Any thoughts ?

It's hard to remember all the options slap has, it would be cool to have the editor autocomplete possible options and maybe even document what's their use.

In clap's master there is a JSON schema we can use: https://github.com/clap-rs/clap/blob/master/clap.schema.json

Context: (If I got it right) the current implementation expects a centralized definition of commands and subcommands. When implementing CLI with multiple nested commands; like these AWS or GCP CLI tools (e.g.: gcloud compute instances describe [...]), that file can become HUGE.

I would love to have each command defined in its own configuration YAML file and then feed these configurations back to slap parse through some multi-valued option like --subcommand_config_path. Giving me the opportunity of structuring the repository according to commands and sub-commands like:

.
└── compute
    ├── instances
    │   ├── create
    │   │   └── slap.yaml
    │   ├── delete
    │   │   └── slap.yaml
    │   ├── describe
    │   │   └── slap.yaml
    │   └── slap.yaml
    └── slap.yaml

Then:

# when running `gcloud compute`
cat ./compute/slap.yaml | slap parse bash _ --subcommand_config_path=./compute/instances/slap.yaml -- "$@"

# when running `gcloud compute instances`
cat ./compute/instances/slap.yaml | slap parse bash _ --subcommand_config_path=./compute/instances/{create,delete,describe}/slap.yaml -- "$@"

So that high-level commands would be simply "routers", looking as simple as:

name: mycommand
version: "1.0"
author: Kevin K. <[email protected]>
about: Does awesome things

global_settings:
  - ColoredHelp

and each nested command would have its own small and concise configuration:

# Example taken from: https://github.com/agnipau/slap/blob/74219a0/examples/simple.yml
# Sub-commands field removed

name: mysubcommand
version: "1.0"
author: Kevin K. <[email protected]>
about: Does awesome things

global_settings:
  - ColoredHelp

args:
  - config:
      short: c
      long: config
      value_name: FILE
      help: Sets a custom config file
      takes_value: true
  - INPUT:
      help: Sets the input file to use
      required: true
      index: 1
  - verbose:
      short: v
      multiple: true
      help: Sets the level of verbosity

Using the following test script:

#!/bin/bash

# shellcheck disable=SC2154

slap deps bat confirm rg sd|| exit 1

eval "$(slap parse bash _ -- "$@" <<-EOF
name: test
version: "0.1"
about: Using an argument that contains '--'

settings:
    - ArgRequiredElseHelp
    - ColorAuto

global_settings:
    - ColoredHelp

args:
    - arg:
        help: The argument
        required: true
EOF
)"; [[ -z "${_success}" ]] && exit 1

printf -- "arg:%s\n" "${_arg_vals}"

Executing ./test value outputs var:value, but executing `./test '--value' leads to

error: Found argument '--value' which wasn't expected, or isn't valid in this context

In my scenario I need to be able to have arguments that start with --.

Is there a workaround ?

The ability to get the absolute path of a script using slap path is a valuable feature ; but after reading the README I'm unsure whether slap path dereferences symlinks, the more so as the non-slap command given as a comparison doesn't.