Consider supporting VAR="with space and $substitution" in `.env`

[huonw]

Continuing #163, it seems that double quotes aren't supported, so it is inconvenient to use .env to set a variable that has both a space in it and does a $ env var substitution, because all the spaces have to be individually \ escaped.

In particular, it'd be nice to have this table have 4 ✅:

.env line	Behaviour	Behaviour is desirable	Comment
A="x $y"	Error	❌	This is the most natural syntax, and would be nice
A=x\ $y	Accepted, with substitution	✅	Annoying for a human to have to write and read all the \s
A='x $y'	Accepted, without substitution	✅	matches the same line in a shell
A=x $y	Error	✅	if accepted, this would have different meaning to the same line in a shell

This is effectively a limitation of dotenvy, e.g. https://github.com/allan2/dotenvy/issues/11. I don't know if another library has different behaviour.

[jsirois]

@huonw presumably you've read through the dotenvy issue; so you realize you're asking scie jump to roll it's own internally or else create a new .env handling crate. The root issue here is that .env is not standardized, but it is prevalent. You're fully aware of the xkcd-worthy traps of either path. Did you have a choice in mind?

[huonw]

Yes, I'm aware that the reality of actually improving this particular feature may make it not worth it (or, maybe just left for some motivated contributor to improve dotenvy first). In any case, dotenvy is an implementation detail of jump, and a consumer like scie-pants doesn't get any contro (e.g. it can't swap it out) so it seems squarely jump's place to consider the .env files it'll accept, even if it's just "whatever dotenvy accepts is fine".

In terms of alternatives, https://github.com/arniu/dotenvs-rs seems to be a little more explicit about what syntax it accepts... but hits https://github.com/arniu/dotenvs-rs/issues/4 (i.e. #163 again, which is more important than this one) so... 🤷‍♂️

Thus, I have no concrete path forward other than either roll-ones-own (bleh), or improving dotenvy (more attractive)... and of course no expectation that you specifically will do either or even keep this issue open 😄

[jsirois]

Ok, thanks for a fuller picture of the request. To complete the picture, afaict the motivating use case is a script that generates a .env file trying to handle source root paths with spaces in them being complicated by the lack of support for using double quotes with interpolation; thus requiring escaping instead. This is a case that is unlikely to exist, but may, and thus is necessary to treat.

Further, the .env file in question is not for use by the scie itself or anything it runs, it merely needs to be parseable so as to not kill the scie. The file will in fact be parsed and used by another program altogether (VSCode).

[jsirois]

Documenting the supported .env format is, of course, the right thing to do no matter the outcome here (#167).

[jsirois]

Alright - dotenvs-rs LGTM; I gave it a go: https://github.com/arniu/dotenvs-rs/pull/5 - we'll see if that gets accepted.

[jsirois]

You won't get item 4 (A=x $y errors), but switching to dotenvs-rs gets you the 1st 3. I think I feel fine documenting this and not policing the shell on its behalf. If A user wants to source their env in the shell, they can let the shell tell them the syntax is bad for it.