[PATCH] Cygwin: pty: Disable clear screen for ssh sessions with -t option.
Mon Oct 21 09:44:00 GMT 2019
On Oct 19 08:50, Takashi Yano wrote:
> Hi Corinna,
> On Fri, 18 Oct 2019 16:33:06 +0200
> Corinna Vinschen wrote:
> > Sorry, but this doesn't look feasible.
> > You can't base the behaviour on the name of an application. What about
> > other applications like telnetd, rshd, just to name the first ones
> > coming to mind? What about a renamed sshd, or sshd installed into
> > another directory, or just an sshd in the build dir during testing?
> > Is this workaround really necessary at all? Even basing this on the
> > terminal name looks pretty fragile.
> I agree with you. However, I couldn't come up with better method.
> Now I have come up with another implementation. Could you please
> have a look at v2 patch?
> As a caution, this patch is for:
> therefore, telnetd or rshd is not targeted.
> > Why exactly is the clear screen necessary? You wrote something about
> > synchronizing the pseudo console and the pseudo tty content, IIRC, but
> > it still seems artificial to enforce a clear screen. Is there no
> > other way to make the pseudo console happy?
> Using cygwin 3.1.0-0.7 (TEST), by the following steps, you can see
> what happens if clear screen is not done.
> 1) Execute ls or ps to draw something to screen.
> 2) env TERM=dumb script
> 3) Execute cmd.exe.
> If we can accept this behaviour, clear screen is not necessary.
I just tried it and what I see is that starting cmd.exe clears the
screen. While starting e.g. reg.exe or sc.exe or w32tm.exe does not
clear the screen. Starting cmd.exe after reg.exe clears the screen and
positions the output of reg.exe at the top. Same if I call a Cygwin
tool between reg.exe and cmd.exe.
So it seems cmd.exe is the only (or one of few) native CLI tools
actually trying to manipulate the screen buffer. And what it does is
not so much clearing the screen, but to align buffer line 1 with the top
of the screen, even if line 1 has been produced before cmd.exe started.
I didn't look deeper into this yet, but the question coming to mind is,
what does GetConsoleScreenBufferInfo return right after starting
`env TERM=dumb script`, how does it look like right after running
`reg.exe' and before `cmd.exe', and how does it look after cmd.exe
The (admittedly vague) idea is, maybe cmd.exe can be cheated into
not changing the console buffer by changing it to what it expects
right after creating the pseudo console...
Also, maybe this effect has something to do with the screen buffer
size in relation to the window size?
Other than that, my very personal opinion here is, not clearing the
screen is more desired than the terminal type and application name (or
SID) hacks just to pamper cmd.exe. Others may disagree, so I'm open to
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Cygwin-patches