Re: [PATCH] t5702: be more resilient to env quoting

From: Jeff King <peff@peff.net>
Date: Nov 4, 2026, 06:32 UTC
Message-ID: <20261104063201.GA1543013@coredump.intra.peff.net>
In-Reply-To: <87jymy5uek.fsf@gmail.com>

On Fri, Oct 30, 2026 at 10:08:35PM -0700, Collin Funk wrote:

Show 10 quoted lines

> Nice catch on the NEWS entry. Sorry to you both for the extra work. I am
> at least partly to blame for those changes.
> 
> In coreutils-9.12, we made 'env' and 'printenv' quote their output. This
> was to make the output more robust in the case of whitespace, special
> characters, and in particular, newlines in environment variables.
> Specifically, any program that parses the output of 'env', without -0,
> will certainly mistake environment variables with newlines in them as
> multiple environment variables. See the following example of the output
> before coreutils-9.12:

Though it created some extra work here, I think this is a good change. There's another spot where we use "env" in the test suite that I was looking at a month or two ago, and I was mildly terrified that it would allow variable injection (though probably not a big deal in practice for our purposes). So I'm happy to see the situation improving.

> In all of the cases that I have seen where the 9.12 behavior caused
> problems, quoting only when standard output is a terminal would have
> avoided all of them.

Yeah, but then we lose the injection protection. :)

What a complicated world we live in.

> Note that some distributions may have also picked up the patch adding
> the --quoting-style option [6] (I think Slackware did, not sure if
> anyone else did). But that hasn't been in a release yet, so you probably
> don't want to use it.

Yeah, I don't have it here yet. I do agree it's good to have, as it lets the caller be careful when they know they're going to eval the result. Though of course it creates its own headaches, because we might not be using coreutils env. :-/

> Sorry again for the extra work of having to investigate that behavior
> change.

No worries, and thanks for the explanation. I think the revised code in git.git is better for not using "env" anyway.

-Peff