On Tue, Feb 25, 2025 at 11:44:33PM +0000, Yaakov Smith wrote:
> In some places, such as trying to fetch a remote with this in the URL, git will render the character differently.
>
> [remote "backslashb"]
> url = "\b"
> fetch = +refs/heads/*:refs/remotes/backslashb/*
>
> $ git fetch backslashb
> fatal: '?' does not appear to be a git repository
> fatal: Could not read from remote repository.
Here we sanitize error output, because we know the result is human
readable (and likely to be showing untrusted input from the repo or a
remote server).
> 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.
> 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.
We could perhaps try to be kinder about sanitizing output when it is
going to a terminal, rather than a pipe. But quite curiously, that
should already be the case for "config --list"! It invokes a pager by
default. Much to my surprise, though, "less" does not seem to treat
backspace as a control character. It can be configured to do so:
$ LESS=FRXU git config --list --local
...
core.foo=true^H^H^H^Hfalse
Here's what the manpage for less(1) says:
By default, if neither -u nor -U is given, backspaces which appear
adjacent to an underscore character are treated specially: the
underlined text is displayed using the terminal's hardware underlining
capability. Also, backspaces which appear between two identical
characters are treated specially: the overstruck text is printed using
the terminal's hardware boldface capability. Other backspaces are
deleted, along with the preceding character.[...]
So I guess it is intentional to allow programs to use some effects, but
in general I think I might prefer them being marked visually. Especially
because the same would be true in a diff, like:
git init
echo old >file && git add file && git commit -m old
printf 'sneaky\b\b\b\b\bnew\n' >file && git commit -m new
git show
which respects the backspaces (actually it says "snew" with a bolded "n"
because of the overstrike rule ;) ).
I wonder if we should consider adding "U" to the default $LESS variable
we set.
-Peff
