-
-
Notifications
You must be signed in to change notification settings - Fork 753
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
cleanup env var semantics #355
Comments
ThomasWaldmann
added a commit
to ThomasWaldmann/borg
that referenced
this issue
Dec 20, 2015
refactorings: - introduced concept of default answer: if the answer string is in the defaultish sequence, the return value of yes() will be the default. e.g. if just pressing <enter> when asked on the console or if an empty string or "default" is in the environment variable for overriding. if an environment var has an invalid value and no retries are enabled: return default if retries are enabled, next retry won't use the env var again, but either ask via input(). - simplify: only one default - this should be a SAFE default as it is used in some special conditions like EOF or invalid input with retries disallowed. no isatty() magic, the "yes" shell command exists, so we could receive input even if it is not from a tty. - clean: separate retry flag from retry_msg
ThomasWaldmann
added a commit
to ThomasWaldmann/borg
that referenced
this issue
Dec 20, 2015
refactorings: - introduced concept of default answer: if the answer string is in the defaultish sequence, the return value of yes() will be the default. e.g. if just pressing <enter> when asked on the console or if an empty string or "default" is in the environment variable for overriding. if an environment var has an invalid value and no retries are enabled: return default if retries are enabled, next retry won't use the env var again, but either ask via input(). - simplify: only one default - this should be a SAFE default as it is used in some special conditions like EOF or invalid input with retries disallowed. no isatty() magic, the "yes" shell command exists, so we could receive input even if it is not from a tty. - clean: separate retry flag from retry_msg
ThomasWaldmann
added a commit
to ThomasWaldmann/borg
that referenced
this issue
Jan 15, 2016
refactorings: - introduced concept of default answer: if the answer string is in the defaultish sequence, the return value of yes() will be the default. e.g. if just pressing <enter> when asked on the console or if an empty string or "default" is in the environment variable for overriding. if an environment var has an invalid value and no retries are enabled: return default if retries are enabled, next retry won't use the env var again, but either ask via input(). - simplify: only one default - this should be a SAFE default as it is used in some special conditions like EOF or invalid input with retries disallowed. no isatty() magic, the "yes" shell command exists, so we could receive input even if it is not from a tty. - clean: separate retry flag from retry_msg
ThomasWaldmann
added a commit
to ThomasWaldmann/borg
that referenced
this issue
Jan 15, 2016
refactorings: - introduced concept of default answer: if the answer string is in the defaultish sequence, the return value of yes() will be the default. e.g. if just pressing <enter> when asked on the console or if an empty string or "default" is in the environment variable for overriding. if an environment var has an invalid value and no retries are enabled: return default if retries are enabled, next retry won't use the env var again, but either ask via input(). - simplify: only one default - this should be a SAFE default as it is used in some special conditions like EOF or invalid input with retries disallowed. no isatty() magic, the "yes" shell command exists, so we could receive input even if it is not from a tty. - clean: separate retry flag from retry_msg
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While implementing helpers.yes function, I noticed that the env_var_override is a bit limited:
You can either not override (== not have the env var set or having it set to an empty value), then it will ask for input from the user.
Or you can override (== have the env var set to anything non-empty), then yes() will return True and not ask the user. It is not possible to override and have yes() return False.
More flexible would be to treat the env var contents in the same way as user inputs, so "y" or "n" in the env var would return True or False and not ask the user for input.
Invalid env var content could just return the default value.
This is a potentially breaking change as currently everything non-empty was accepted as truish, which would be changed when implementing this.
The text was updated successfully, but these errors were encountered: