On 29/08/2026 20:56, Collin Funk wrote:
Pádraig Brady <[email protected]> writes:
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.
I think I agree. It feels a little weird to behave differently based on
the number of arguments, but I think that case warrants it.
It would be a bit more consistent to key on whether args were specified at all.
So 1 or more args would only quote if connected to a tty.
I've attached an incomplete patch to do that. I'll probably adjust NEWS
and the documentation a bit.
NEWS is fine I think.
Details on this are best restricted to the texinfo description.
One thing I'm unsure about is whether a test for tty output should be
added to the same test or in misc/tty-quoting.sh. It seems like the ones
there are tailored to a single argument, where we should test both
single argument and multiple arguments in this case, I think. I don't
want that look to be *too* full of edge cases such that it gets
difficult to understand. WDYT?
It would be good to add the arg specified case to tty-quoting.sha
to document the commands that are tty sensitive.
A single arg case is fine here.
The existing cases are fine in misc/printenv.sh,
but tweaked to the adjusted non quoting.
thanks!
Padraig
