Re: \b character escapes in CLI usage

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Feb 26, 2025, 23:36 UTC
Message-ID: <Z7-lbGnlzGbhrHZN@tapette.crustytoothpaste.net>
In-Reply-To: <20250226073822.GA21138@coredump.intra.peff.net>

On 2025-02-26 at 07:38:22, Jeff King wrote:

Show 12 quoted lines

> On Tue, Feb 25, 2025 at 11:44:33PM +0000, Yaakov Smith wrote:
> > When using "git config --list" however, this is emitted in its raw format, and can be used to mask or hide an actual (probably invalid) value:
> > 
> > $ cat .git/config
> > [core]
> >         somevalue = "true\b\b\b\bfalse"
> > $ git config --local --list
> > core.somevalue=false
> 
> But here, the point of "git config" is to show the output. If we
> sanitized it (especially in a lossy way like we do for error messages),
> then any program reading the output would not see the real data.

Yes, I should point out that, among other programs, Git LFS reads this output. Changing the output format would break those programs.

> > Should "git config" be smarter here and print something other than a
> > literal backspace to the terminal, like "git fetch" does?
> 
> So I would say no here, in general.

I agree this is the right choice in general. I wonder if we might want some sort of human-readable output option that might escape these that users could use. The output might still be machine-readable, but it might be easier to parse than the current format, which has some tricky edge cases when a config value contains newlines.

We already have precedent for this in core.quotePath and could easily use similar logic here. That format, while using octal, which I find ugly and hard to read, does have the pleasant side effect that it works correctly with POSIX printf(1) (which I'm sure was intentional), unlike hex escapes.

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA