-
-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Access default value #562
Comments
What is the reason for cramming multiple options inside a single flag? Why not a separate flag for each option? Wouldn't that make it both simpler to the user and the developer? |
I was trying to keep a degree of parity with the tool I'm wrapping and how they do it. In this case the tool is |
I see. The use case is quite irregular, so I am not sure the value outweighs the introduced complexity and potential confusion. flags:
- long: --default-option
arg: option
repeatable: true
private: true
default: &options
- permit-agent-forwarding
- permit-port-forwarding
- permit-pty
- long: --option
arg: option
help: Options to add to the certificate
repeatable: true
default: *options Running it will provide: $ ./cli
args:
- ${args[--default-option]} = permit-agent-forwarding permit-port-forwarding permit-pty
- ${args[--option]} = permit-agent-forwarding permit-port-forwarding permit-pty Is this acceptable? |
... or perhaps with better show of intent: flags:
- &options
long: --option
arg: option
help: Options to add to the certificate
repeatable: true
default:
- permit-agent-forwarding
- permit-port-forwarding
- permit-pty
- <<: *options
long: --default-option
private: true (same result) |
Yeah, that's a clever solution. Thanks! I'll go ahead and do it that way. Feel free to close this ticket out if you'd like. |
Good. I am keeping this open, as I am still considering if there is a place for a feature that makes this more straight forward. |
@zeroSteiner how do you feel about this: # bashly.yml
name: cli
help: Sample application
version: 0.1.0
# This is the new section
variables:
- name: default_cert_options
value: &default_cert_options
- permit-agent-forwarding
- permit-port-forwarding
- permit-pty
flags:
- long: --option
arg: option
repeatable: true
default: *default_cert_options which will simply add a section as the first thing in the command's function: root_command() {
# :command.variables
declare -a default_cert_options=( # <= This (can be anything, including array or dictionary)
"permit-agent-forwarding"
"permit-port-forwarding"
"permit-pty"
)
# src/root_command.sh
for key in "${!default_cert_options[@]}"; do
echo "$key: ${default_cert_options[$key]}"
done
} |
I like that solution a lot and think it'd fit my use case very nicely. I imagine it'd be even more useful, as you could have things like URI endpoints and path defaults defined for subcommands instead of placing them in |
Excellent. I have already created a pull request with this feature - I can merge it to master, and then you will have an |
Yes, I'd be very happy to help test it but it may take me a day or two. Thank you for working on it. |
No pressure. Instructions for installing unreleased version are here: |
Description
First, thanks so much for your work on bashly, it's a fantastic project.
I'm hoping to request a feature to access the default value from the YAML definition to prevent the need for repeating it in the bash code. For my use case, I have this option definition:
When the user specifies the
--option
flag, the defaults are all removed. My use case is probably uncommon, but I'd like to maintain the array to allow the user to pass multiple keys prefixed withpermit
orno
and they'll be merged into the result as a set of enabled options. I have all of that working, but as it is now I have to have my defaults defined both in the YAML so they can be shown to the user and in the bash code, so that if only one flag is disabled the others will still be set. Basically, I'd like to be able to merge them myself by detecting the value ofargs[--option]
isn't the default like this (assuming the function namedarg_option_default
returns the default value):I was thinking there would probably be other use cases for checking if a value is non-default as well but I guess an alternative solution could be a flag to allow
repeatable
options to be appended to the specified default.The text was updated successfully, but these errors were encountered: