X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2A9A13A78016
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1620292570;
	bh=naqcStPYSQFB9Q95OwBWsy+Uy8d0YkuYOdIdFY7vzFE=;
	h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=J8Qgzoyw2nIj4vWdx21UvmFmzYHrwVn/TCN8pK9c+0ynxXWPEP0FK6KvrY754dxH5
	 /JYMrtnj+MI+dG0QzcPLGK/76WU65rtEyBmdwqlCJtSQCNzsSHaOIrqn/noESQsIre
	 fT28lXnUqmstJ6gPSlEro3XfRRLDjQma+e4IGpGk=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9CD02388C02A
DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 1469FksX026802
X-Nifty-SrcIP: [124.155.50.190]
Date: Thu, 6 May 2021 18:15:59 +0900
To: cygwin AT cygwin DOT com
Subject: Re: Screen clearing in CMD without "Legacy Console Mode"
Message-Id: <20210506181559.026085c3284c1b92b4aea598@nifty.ne.jp>
In-Reply-To: <20210506181238.798ef704f5f7d77a89107ea8@nifty.ne.jp>
References: <YIwTSMfJu9uMwrKn AT kevinlocke DOT name>
 <20210430235358 DOT 2ae6daa41e3f0b6cb0daa173 AT nifty DOT ne DOT jp>
 <YIwcGRttJhUueeRG AT kevinlocke DOT name>
 <nycvar DOT QRO DOT 7 DOT 76 DOT 6 DOT 2105051500410 DOT 50 AT tvgsbejvaqbjf DOT bet>
 <20210506181238 DOT 798ef704f5f7d77a89107ea8 AT nifty DOT ne DOT jp>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version: 1.0
X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE,
 SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Takashi Yano via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>

On Thu, 6 May 2021 18:12:38 +0900
Takashi Yano via Cygwin> wrote:
> On Wed, 5 May 2021 15:07:04 +0200 (CEST)
> Johannes Schindelin wrote:
> > Hi,
> > 
> > On Fri, 30 Apr 2021, Kevin Locke wrote:
> > 
> > > On Fri, 2021-04-30 at 23:53 +0900, Takashi Yano wrote:
> > > > On Fri, 30 Apr 2021 08:25:12 -0600 Kevin Locke wrote:
> > > >> I'm investigating an issue in Git for Windows[^1], which also affects
> > > >> Cygwin.  The issue is that, when using CMD (i.e. Command Prompt) on
> > > >> Windows 10 1703 or above with "Legacy Console Mode"[^2] disabled, if
> > > >> TERM=cygwin is set in the environment, the console is not cleared when
> > > >> vi exits.  To demonstrate, with Cygwin 3.2.0, in CMD with "Legacy
> > > >> Console Mode" disabled:
> > > >>
> > > >> cd C:\cygwin64
> > > >> set TERM=cygwin
> > > >> bin\vi etc\bash.bashrc
> > > >> :q
> > > >>
> > > >> After exiting vi, the console window has not been cleared and content
> > > >> from etc\bash.bashrc remains visible, making further use of the console
> > > >> difficult until cleared.
> > > >
> > > > Why on earth do you want to set TERM=cygwin?
> > > > If you don't set TERM=cygwin, TERM is automatically set to
> > > > xterm-256color, in which the issue does not occur.
> > 
> > TERM=cygwin would be correct right until the time when you toggle
> > `ENABLE_VIRTUAL_TERMINAL_PROCESSING` under our feet.
> > 
> > That is, when the Cygwin process is called, this flag is not set, so
> > `TERM=xterm-256color` would be incorrect. And then when the Cygwin process
> > returns, the flag is set, and the calling process should somehow guess
> > that `TERM` should be set differently.
> > 
> > Oh, and you probably expect the caller to then figure out whether the flag
> > was _actually_ toggled, just in case we're running on a Windows 10 version
> > that is too old to understand that flag.
> > 
> > If you expect CMD to be no longer used after the Cygwin process returns,
> > that might be a valid world view. But that is probably not a very tenable
> > world view.
> 
> If you don't set TERM, cygwin sets right value automatically.
> That is, in the case in which ENABLE_VIRTUAL_TERMINAL_PROCESSING
> is not supported, TERM will be set to 'cygwin', otherwise, it
> will be set to 'xterm-256color'.
> 
> Why do you want to set TERM? What is wrong with not setting TERM
> manually? If you set TERM incorrectly, it is very natural result
> that apps does not work correctly.
> 
> > If Cygwin is unable to handle `TERM=cygwin` correctly when
> > `ENABLE_VIRTUAL_TERMINAL_PROCESSING` is toggled, then Cygwin should
> > definitely, absolutely, with 100% certainty _not_ toggle that flag when
> > `TERM` is already set to `cygwin`!
> 
> I don't think so AT ALL. If someone sets TERM to the value other 
> than 'cygwin' and 'xterm-256color', what do you expect cygwin to
> behave? For example, if TERM is set to 'linux', how should cygwin
> behave, do you think?
> 
> P.S.
> mintty overwrites the TERM at startup even if user sets TERM manually.
> Shouldn't cygwin console also overwrite TERM to the correct value?

WSL also overwrites TERM value to 'xterm-256color'.

-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple