public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: cygwin@cygwin.com
Subject: Re: Screen clearing in CMD without "Legacy Console Mode"
Date: Thu, 6 May 2021 18:12:38 +0900	[thread overview]
Message-ID: <20210506181238.798ef704f5f7d77a89107ea8@nifty.ne.jp> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2105051500410.50@tvgsbejvaqbjf.bet>

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?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

  reply	other threads:[~2021-05-06  9:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 14:25 Kevin Locke
2021-04-30 14:53 ` Takashi Yano
2021-04-30 15:02   ` Kevin Locke
2021-05-05 13:07     ` Johannes Schindelin
2021-05-06  9:12       ` Takashi Yano [this message]
2021-05-06  9:15         ` Takashi Yano
2021-04-30 16:40   ` Brian Inglis
2021-04-30 17:11     ` Takashi Yano
2021-04-30 18:00   ` Jack Adrian Zappa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210506181238.798ef704f5f7d77a89107ea8@nifty.ne.jp \
    --to=takashi.yano@nifty.ne.jp \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).