Update substring parser to comply with Bash's rules #7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The substring parser is a Bash extension to POSIX Parameter Expansion, and it turns out our parsing has been different from how Bash's works for a while now, causing the singular gotcha that it is impossible to substitute a numeric value in the default value expansion.
For example, this expansion:
${EMPTY:-127}
works in Bash and Zsh, giving you a result of127
ifEMPTY
is unset, however, the same expansion is treated as a negative-offset substring expansion by interpolate, meaning you end up with a blank value rather than the expected default.This seems to have been written this way intentionally, but it seems to be an oversight.
I've updated the parser to not special-case a numeric character following the :- operator, as the Bash-approved way is to require a space character after the - to disambiguate the two similar, but distinct functions. I’ve also updated the documentation to point that out, and all the tests to comply with this rule.