Variable Expansion Divergence

[shellscape]

Howdy. I recently opened up moonrepo/moon#760 which is a project using dotenvy.

I wanted to raise a situation that we ran across with variable expansion and the need for curly brackets in order for dotenvy to parse successfully. In the past, we've used an .env file that looks like this:

export NODE_ENV=dev
export DEPLOY_ENV=$NODE_ENV

This works really well with both source .env (via shell) as well as parsers like the Node-standard https://github.com/motdotla/dotenv. Kudos for dotenvy also supporting export by the way. Recently we used a similar file with moon, which uses this project for its .env file needs, and were getting some unexpected results. The value for $DEPLOY_ENV was;

• using source: dev
• using Node dotenv: dev
• using dotenvy: _ENV

The moon devs pointed out that we might have to use curly brackets, changing the file to:

export NODE_ENV=dev
export DEPLOY_ENV=${NODE_ENV}

And that worked fine, with dotenvy returning dev as expected. Here's where I think dotenvy diverges from the spec:

echo $SHELL is a parameter expansion, and parameters can contain underscores (https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html), so substituting and empty string for the $DEPLOY portion of $DEPLOY_ENV is likely a bug. Curly brackets are only necessary for positional expansion or when the character that follows isn't a part of the variable/parameter name (https://tldp.org/LDP/Bash-Beginners-Guide/html/sect_03_04.html) so it looks like there's a possible bug in the implementation around that in dotenvy as well.

[gibbz00]

Issues also arise when using the same syntax for a $DATABASE_URL.

$DATABASE_URL="postgres://$POSTGRES_DB_USER:$POSTGRES_DB_PASSWORD@localhost:$POSTGRES_DB_PORT/$POSTGRES_DB_NAME"

Both sqlx and diesel fail to read the env var in this format.

[polarathene]

An alternative crate dotenvs does not reproduce any of the failure cases noted by the two comments above.

It may be a viable replacement to consider in the meantime?

[mantmorre]

@allan2 Would you like to flag this behavior as intended? If not, I can go ahead and create a draft PR (or maybe a full PR) implementing a fix for this.