On 06/08/2026 05:54, Collin Funk wrote:
Pádraig Brady <[email protected]> writes:
Yes, it makes sense to quote even when redirecting (unless QUOTE_STYLE=literal) as we were discussing at: https://github.com/coreutils/coreutils/issues/324 One small worry is breaking usage like: foo=$(printenv foo) or popen("printenv foo"). But that's not a practical concern as it's much more natural to access particular env vars directly. I did audit the following just in case: https://codesearch.debian.net/search?q=printenv.*\|.*(cut|sed)&literal=0 but noticed no problematic usage. In fact quoting newlines in env var values would make the found usages more robust.In the more general cases (ignoring many that are obvious tests), I have found it is mostly stuff like this: $ printenv LC_ALL [...] That one should obviously not be defined in a way that needs quoted. I have also seen stuff like this: $ printenv | grep '^SSH_' [...] That one should probably not ever have the need to be quoted, but I guess it is possible. In any case, that one would be buggy if someone defines an environment variable with "SSH_" following a newline.
Thinking a bit more about this, it might be safer to limit the single variable case to only quote to tty by default. For example to support usage like: user_color=$(run0 --user="$user" printenv user_color) E.g. if $user_color contained ANSI escapes we'd want them unquoted. Note the trailing newline would be auto stripped in the above, allowing such usage. cheers, Padraig
