Make CARGO_BIN_EXE_ available with underscores substituted for hyphens

[sunshowers]

Problem

(Cross-posting from #16421 (comment))

Many environments such as shells and debuggers silently drop environment variable keys which have hyphens in them, or otherwise do not work with these kinds of environment variables. So CARGO_BIN_EXE_foo is okay, but CARGO_BIN_EXE_my-program is silently dropped.

(Values are free to have hyphens in them -- it's just keys that are affected.)

These environments include:

• RUSTC_WRAPPER at build time, if it's a shell script
• Cargo target runners (with feat(test): Make CARGO_BIN_EXE_ available at runtime  #16421)
• rust-gdb and rust-lldb on Linux based on my experimentation

Proposed Solution

Make a version of these variables available that replaces hyphens with underscores, e.g. CARGO_BIN_EXE_my_program. (I'm not sure if Cargo only allows one of my_program and my-program to exist.)

Notes

No response

[epage]

Do you have links out to the end-user requests or documentation for more information on these environment variables being dropped?

[epage]

I guess one thing I'm wondering is why we haven't seen a report of this before.

[sunshowers]

Do you have links out to the end-user requests or documentation for more information on these environment variables being dropped?

https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html

Environment variable names used by the utilities in the Shell and Utilities volume of POSIX.1-2024 consist solely of uppercase letters, digits, and the ('_') from the characters defined in Portable Character Set and do not begin with a digit.

It looks like bash and zsh do preserve it if you do something like:

env 'MY-VAR=value' zsh -c 'env | grep MY-VAR'

But note that you can't just do the usual MY-VAR=value <program>.

In my testing (and how I ran into this), rust-gdb and rust-lldb drop these variables as well (though this seems to be done by the Rust wrappers and not gdb and lldb themselves):

$ env 'MY-VAR=value' rust-gdb -ex 'show environment MY-VAR'
...
Environment variable "MY-VAR" not defined.

Regardless, I think we should be portable.

[epage]

https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html

That is speaking to utilities written in a shell language which I can understand do to syntax constrains. Unsure how important that is for our use cases.

In my testing (and how I ran into this), rust-gdb and rust-lldb drop these variables as well (though this seems to be done by the Rust wrappers and not gdb and lldb themselves):

Is that instead a bug within those wrappers? Or is it in a shell language and the shell isn't preserving in this case?

[sunshowers]

It looks like that's because sh (which in my Ubuntu installation is set to dash) drops this.

https://github.com/rust-lang/rust/blob/main/src/etc/rust-gdb uses sh for portability.

env 'MY-VAR=value' sh -c 'env | grep MY-VAR'

prints no output. So if someone uses a RUSTC_WRAPPER or target runner that uses dash via sh, this will be dropped.

[sunshowers]

https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=46d3c1a614f11f0d40a7e73376359618ff07abcd is the commit that banned hyphens (via https://unix.stackexchange.com/a/23714). Also see https://stackoverflow.com/questions/36989263/why-cant-environment-variables-with-dashes-be-accessed-in-bash-4-1-2.

[epage]

So the reason dash banned them

"export -p" prints all environment variables, without checking if the > environment variable is a valid dash variable name.

IMHO, the only valid usecase for "export -p" is to eval the output.

The other links seem to only be relevant for bash/dash accessing these variables or setting them

[epage]

Probably the most interesting quote for when shells are invoked is from http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

It is unspecified whether environment variables that were passed to the shell when it was invoked, but were not used to initialize shell variables (see Shell Variables) because they had invalid names, are included in the environment passed to execl() and (if execl() fails as described above) to the new shell.