{ is an undefined environment variable, so ${ is expanded to empty string. I think it's working as intended. Environment variable is not the same as shell variable.

It's not and it shouldn't. The code here points out that ${ is bad syntax. I guess what I'm trying to say is that it shouldn't be "eaten."

Concrete example: Running ExpandEnv over a YAML file whose last line looks like this:

  password: abcd${efgh

will, IMHO, incorrectly clobber the password.

It's not and it shouldn't. The code here points out that ${ is bad syntax. I guess what I'm trying to say is that it shouldn't be "eaten."

Concrete example: Running ExpandEnv over a YAML file whose last line looks like this:

  password: abcd${efgh

will, IMHO, incorrectly clobber the password.

Hmm, it's also not consistent, since when we can do os.Setenv("{", "foo") then os.Getenv("{") will return foo, but ExpandEnv does not.

I think it's better to just improve the document of ExpandEnv to indicate that the expansion follow the rule of shell expansion, invalid syntax will return empty string.

/cc @josharian @mvdan @ianlancetaylor @bradfitz

I agree that we should mention this in the documentation and not change the behavior of the function.

In another case Expand was fixed:
#24345
Perhaps in this case ExpandEnv should be fixed too.

There is no significant difference between Expand and ExpandEnv.

See also #26135.

That said, I think you are suggesting that for ${ with no } we should keep the ${. That may be OK.

Change https://golang.org/cl/208857 mentions this issue: os: add documentation for invalid expansion syntax in ExpandEnv

you are suggesting that for ${ with no } we should keep the ${.

Yep. It's not even like ExpandEnv replaces ${ with a value of the { variable: https://play.golang.org/p/CzLSGzkLAWx

I'm looking at picking up an issue for a first contribution, and it looks as though this is a candidate. Is that actively being addressed by anyone? It looks like there is still a decision to be made on the expected behaviour.