Re: [PATCH] Cygwin: pty: Disable clear screen for ssh sessions with -t option.
On Mon, 21 Oct 2019 11:43:56 +0200 Corinna Vinschen wrote: > 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. What is done is not clearing the screen, but redrawing the screen based on the screen buffer. This is done not by cmd.exe but by pseudo console, I believe. The trigger for redrawing is not clear to me. You can see what is done by pseudo console by checking "typescript" generated by script. > 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 > changed it? I confirmed the dwSize has right screen size and dwCursorPosition is (0,0) just after creating pty even though the cursor position in real screen is not at top left. Clearing screen fixes this mismatch. > 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... To do this, it is necessary to log past data written to pty and push them into console screen buffer when pseudo console is started. The console screen buffer is empty just after creating pseudo console, therefore, clearing screen is the simplest way to match the real screen with the console screen buffer. -- Takashi Yano
Re: [PATCH] Cygwin: Provide more COM devices
Corinna Vinschen writes: > That's not the right way to patch this. devices.cc gets generated from > devices.in by the gendevices script which in turn calls shilka from the > cocom package. Now that you mention it I remember… :-( > Apart from the struct members you added here, it will > also add some code. Which, unfortunately, raise the size of devices.cc, > especially troubling the 32 bit version. So how about we only do this on 64bit as an added bonus for folks who "get it"? One particular machine I've recently worked on presented me with COM144 to connect to, but I consider this to be an anomaly. But COM port numbers in the 70…80 range are pretty common on some of the more heavily used development machines. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH] Cygwin: pty: Disable clear screen for ssh sessions with -t option.
On Oct 21 19:55, Takashi Yano wrote: > On Mon, 21 Oct 2019 11:43:56 +0200 > Corinna Vinschen wrote: > > 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. > > Powershell also redraws the screen. > netsh is even worse. The cursor position will be broken by the follwing > steps. > > 1) env TERM=dumb script > 2) netsh > 3) winhttp show proxy > > > 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 > > discussion. > > Even with Microsoft-provided OpenSSH server, the screen is cleared > upon login. Therefore, clearing screen is not so strange, I suppose. Yes, but I assume this is done in MSFT's OpenSSH server, not in the kernel or system lib To me the problem is if it breaks Cygwin scenarios. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] Cygwin: pty: Disable clear screen for ssh sessions with -t option.
On Mon, 21 Oct 2019 19:55:15 +0900 Takashi Yano wrote: > netsh is even worse. The cursor position will be broken by the follwing > steps. > 1) env TERM=dumb script > 2) netsh > 3) winhttp show proxy wmic also has the cursor position problem. 1) env TERM=dumb script 2) /cygdrive/c/windows/system32/wbem/wmic 3) computersystem list brief -- Takashi Yano
Re: [PATCH] Cygwin: pty: Disable clear screen for ssh sessions with -t option.
On Mon, 21 Oct 2019 11:43:56 +0200 Corinna Vinschen wrote: > 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. Powershell also redraws the screen. netsh is even worse. The cursor position will be broken by the follwing steps. 1) env TERM=dumb script 2) netsh 3) winhttp show proxy > 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 > discussion. Even with Microsoft-provided OpenSSH server, the screen is cleared upon login. Therefore, clearing screen is not so strange, I suppose. -- Takashi Yano
Re: [PATCH] Cygwin: pty: Disable clear screen for ssh sessions with -t option.
Hi Takashi, 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: > https://www.cygwin.com/ml/cygwin/2019-10/msg00074.html > 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 changed it? 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 discussion. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] Cygwin: Provide more COM devices
Hi Achim,
On Oct 20 15:27, Achim Gratz wrote:
>
> This was requested on IRC.
>
> >From a80b1c9ba67f94237948e85ad2dee744cdfbdcad Mon Sep 17 00:00:00 2001
> From: Achim Gratz
> Date: Sun, 20 Oct 2019 15:23:04 +0200
> Subject: [PATCH] Cygwin: provide more COM devices
>
> * winsup/cygwin/devices.cc: Add another 64 COM devices since Windows
> likes to create lots of these over time (one per identifiable device
> and USB port).
> ---
> winsup/cygwin/devices.cc | 64
> 1 file changed, 64 insertions(+)
>
> diff --git a/winsup/cygwin/devices.cc b/winsup/cygwin/devices.cc
> index 2e31ca366..7a57459d8 100644
> --- a/winsup/cygwin/devices.cc
> +++ b/winsup/cygwin/devices.cc
> @@ -798,6 +798,70 @@ const _RDATA _device dev_storage[] =
>{"/dev/ttyS61", BRACK(FHDEV(DEV_SERIAL_MAJOR, 61)), "\\??\\COM62",
> exists_ntdev, S_IFCHR, true},
> [...]
That's not the right way to patch this. devices.cc gets generated from
devices.in by the gendevices script which in turn calls shilka from the
cocom package. Apart from the struct members you added here, it will
also add some code. Which, unfortunately, raise the size of devices.cc,
especially troubling the 32 bit version.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
