Add support for shell parameter substitution modifiers

[nthuemmel-scontain]

This adds support for the basic shell parameter substitution modifiers (which make sense for this crate), as described in https://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02

Namely, it adds the following features:

• Use default values if a variable is unset or empty (${VAR:-default} or ${VAR-default})
• Error out of a variable is unset or empty (${VAR:?} or ${VAR?})
• Replace value if a variable is set (${VAR:+replacement} or ${VAR+replacement})

[allan2]

Thanks for this detailed PR.

Tasks for review:

• See if dotenv libraries in other languages, such as Ruby and go, support this functionality.
• POSIX-shell compliance is not a current goal of this library. I'd see if there is anything else not POSIX-compliant currently implemented, to see if it should be a goal.

If you or anyone has time to help with those tasks, that would be great. Otherwise, I will start looking into it in a week!

[nthuemmel-scontain]

• See if dotenv libraries in other languages, such as Ruby and go, support this functionality.

• Example for Ruby - gem dotenv - does not seem to support this: Only subset of shell functionality is supported bkeepers/dotenv#430
• Example for go - godotenv - does not support this: Variable in the form VAR="${VAR:-default}" does not parse correctly joho/godotenv#211
• Example for python - python-dotenv - does not support this: Does not execute default values, subshells, etc. theskumar/python-dotenv#402

Though the issues - and demand for such functionality - seem to be there ;)

• POSIX-shell compliance is not a current goal of this library. I'd see if there is anything else not POSIX-compliant currently implemented, to see if it should be a goal.

I don't think full POSIX-shell compliance should be a goal either, especially regarding the security implications of spawning arbitrary subshells. However, some features, like default values in variable substitutions, do not have these implications and are simply nice-to-have. As long as these features are properly documented and maintainable, it still makes sense to support them without full POSIX-shell compliance, from my perspective.
The second sentence ("I'd see if there is anything else not POSIX-compliant currently implemented, to see if it should be a goal") I don't fully understand, to be honest.

[allan2]

@nthuemmel-scontain, thank you for the detailed reply.

I'm going to sit on this for now, update the API, and then come back to this potential feature.

#19 related

[tib-rijo]

See if dotenv libraries in other languages, such as Ruby and go, support this functionality.

Docker Compose uses this. E.g. in a mise run = statement, loading the .env file prior to invoking docker compose will overlay all variables in the environment, but without applying variable substitution modifiers. This leads to configuration drift.

The Docker Compose interpolation syntax is often very useful to construct values.