Repository navigation
Conversation
natefinch
reviewed
Oct 2, 2026
natefinch
left a comment
Member
There was a problem hiding this comment.
Thanks for tackling literal dollar signs in command arguments. I applied this patch to current master (0953947) to review it. I found two compatibility regressions that need addressing before merging; the inline comments include reproductions. The Escape round-trip worked in the cases I exercised, but replacing os.Expand also changes behavior for existing arguments unrelated to dollar escaping.
The updated patch also needs a small lint cleanup: use strings.ReplaceAll, fix the spelling of preceding, and use t.Setenv in the precedence test.
The `sh.Exec` family of functions used to use `os.Expand` to expand environment variables in command arguments, but that function offers no escape syntax -- no way to avoid expanding dollar signs that the caller really wants to include on the command line. This commit implements a new, mostly compatible `Expand` function to allow escaping the environment-variable syntax, plus an accompanying `Escape` function to produce escaped strings. This technically breaks backward compatibility: Any existing code that has used the sequence "\\" or "\$" in its command arguments will need to be updated. Although Go's compatibility promise prevents `os.Expand` from changing, documentation for `sh.Exec` hasn't actually stated that it follows all the same rules as `os.Expand`, so it's possible to view this change as merely a bugfix, formalizing a new syntax that had not previously been established. Fixes magefile#434
They had previously been removed, on the grounds that they were reserved for future use, but now they'll just be passed back verbatim -- no longer reserved.
This is "new" with respect to the Go versions supported at the time the surrounding code was written.
The stdlib function accepts different syntax depending on whether braces are used, and now our `Expand` function will behave likewise. Unit tests that involve new backslash-escape syntax have hard-coded expected results, but all other tests of `sh.Expand` defer to `os.Expand` as their oracle.
rkennedy
force-pushed
the
bugfix/env-expand
branch
from
October 2, 2026 22:30
58d81dd to
37727af
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
sh.Execfamily of functions used to useos.Expandto expand environment variables in command arguments, but that function offers no escape syntax — no way to avoid expanding dollar signs that the caller really wants to include on the command line. This commit implements a new, mostly compatibleExpandfunction to allow escaping the environment-variable syntax, plus an accompanyingEscapefunction to producing escaped strings.This technically breaks backward compatibility; any existing code that has used the sequences "\\" or "\$" in its command arguments will need to be updated. Although the compatibility argument prevents
os.Expandfrom changing, documentation forsh.Exechasn't actually stated that it follows all the same rules asos.Expand, so it's possible to view this change as merely a bugfix, formalizing a new syntax that had not previously been established.Fixes #434