cargo
cargo copied to clipboard
rust-lang
environment variables are not parsed correctly
Problem
RUSTFLAGS="--output '/home/somewhere/out file'" cargo doc
With this command, the --output command will receive /home/somewhere/out and not /home/somewhere/out file, which is problematic
Steps
Add any flag with whitespace characters to environment variables.
Possible Solution(s)
Correctly parse arguments passed through environment variables.
Notes
No response
Version
No response
I didn't know about CARGO_ENCODED_RUSTFLAGS and CARGO_ENCODED_RUSTDOCFLAGS. Why is it not the default behaviour?
I was not there and have no relevant context. CARGO_ENCODED_RUSTDOCFLAGS seems to be added because of the lossy RUSTFLAGS issue was found during a discussion of an unrelated issue.
Just wanted to note that we generally wanted to avoid any parsing of RUSTFLAGS. Over the years, we have introduced several alternatives (some documented here).
Another alternative is to support TOML instead of shlex as suggested here.
Although not a strong concern, I think it is worth being wary that shell quoting styles are not universal. The shlex docs themselves don't document the exact grammar that it supports.
I'm also not convinced that it wouldn't be a breaking change to change the syntax for RUSTFLAGS.
I am slightly inclined to close this as "won't fix" since there are several alternatives that already exist.
We could specify which quotes are supported and what would be the end result. Because currently, this is an issue you discover randomly, which is pretty bad.
With this command, the --output command will receive /home/somewhere/out and not /home/somewhere/out, which is problematic
Er, you may wish to amend your report given that currently you are technically reporting that "/home/somewhere/out" is a different string from `"/home/somewhere/out", which... is not the case and also not, I think, what you wanted to report.
I am slightly inclined to close this as "won't fix" since there are several alternatives that already exist.
I concur with ehuss and am closing this in favor of the other solutions we provide.
