Re: win-test: unknown terminal "xterm-256color", was Re: [RFC PATCH 6/6] ls-tree: introduce '--pattern' option

[Jeff King <peff@peff.net>]

On Tue, Mar 28, 2023 at 12:31:59PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > So it should be fine to just set TERM=dumb everywhere. What actually
> > confuses me is that we try to do so already:
> >
> >   $ git grep -B1 dumb ci/lib.sh
> >   ci/lib.sh-# GitHub Action doesn't set TERM, which is required by tput
> >   ci/lib.sh:export TERM=${TERM:-dumb}
> >
> > Pushing a stripped-down workflow file to just run "echo $TERM" shows
> > that it seems to already be set by Actions to "dumb" on ubuntu-latest,
> > but is xterm-256color on windows-latest.
> >
> > So maybe we just want to make the line above unconditionally set $TERM?
> 
> I thought that Dscho earlier said xterm-256 is set by mingw when
> nothing is set to TERM, which explains why TERM=${TERM:-dumb} is
> not good enough to "fix" this one for them.

Ah, I took it to mean that in our code, we'd default to xterm256-color.
But perhaps it is the outer bash which is doing so, via that runtime. I
tested with a dummy workflow like:

  name: fake ci
  on: [push, pull_request]
  jobs:
    ubuntu:
      runs-on: ubuntu-latest
      steps:
        - name: check TERM
	- run: |
	  echo TERM=$TERM
    windows:
      runs-on: windows-latest
      steps:
        - name: check TERM
          shell: bash
          run: |
            echo TERM=$TERM

and got "dumb" for ubuntu (which is not set by us; this is before
ci/lib.sh is run) and "xterm256-color" for windows (I guess because it's
mingw bash).

At any rate, unconditionally setting TERM=dumb should cover all cases,
I'd think. I'm happy to prepare a patch.

-Peff