Re: \b character escapes in CLI usage

From: Jeff King <peff@peff.net>
Date: Feb 26, 2025, 07:38 UTC
Message-ID: <20250226073822.GA21138@coredump.intra.peff.net>
In-Reply-To: <SYBPR01MB579278DD5EC6E13CA9A213FDE2C32@SYBPR01MB5792.ausprd01.prod.outlook.com>

On Tue, Feb 25, 2025 at 11:44:33PM +0000, Yaakov Smith wrote:

Show 9 quoted lines

> 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).

Show 7 quoted lines

> 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