[SAY-5]

When a value contains a ', set_key previously emitted \' inside a single-quoted shell value, which is not valid POSIX shell (so source .env fails) and does not round-trip through dotenv's parser. Such values are now written double-quoted with \ and " escaped, which is shell-source-safe and parses back to the original value. Closes #543.

[SAY-5]

Ping on this. The gist is that set_key writes \' inside a single quoted value, which isn't valid POSIX shell, so source .env fails and the value doesn't round trip through the parser either (#543). Writes those double quoted now.

[SAY-5]

Rebased on top of #680. That one fixed the parser round-trip by escaping the quote inside the single-quoted value, but the line it writes (VAR='I\'m a bug') still isn't valid shell, which is the part #543 is actually about, so this keeps the double-quoted form for values containing a ' and leaves #680's backslash escaping in place for everything else. Test expectations updated accordingly.

[lexingtonhibiki]

AI-assisted independent check at ea79fc9d983589d77603c912c9c5bc1e9548bedd: the default, non-export output still changes a literal value when sourced.

With DOTENV_PROBE=expanded, this call:

set_key(path, "VALUE", "I'm $DOTENV_PROBE")

writes VALUE="I'm $DOTENV_PROBE". dotenv_values(path, interpolate=False)["VALUE"] returns the original I'm $DOTENV_PROBE, but sourcing the file in bash gives I'm expanded.

Could a regression test require the original value through both readers? #670 handles shell escaping for export=True, but does not cover this default path. Simply escaping the dollar also needs a dotenv-readback check: VALUE="I'm \$DOTENV_PROBE" currently retains the extra backslash in the parsed value.

I reproduced this using only temporary files and generated literal values on Linux/Python 3.12. The variable case fails with both always and auto; plain apostrophe and multiline/backslash controls pass. Main is not a passing shell baseline either: its apostrophe output fails shell syntax. This is an incomplete round-trip fix, not a claim that the original shell path worked. I have not run the full upstream suite; no human-review approval is claimed.