This is the mail archive of the cygwin-patches mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |