Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
Hi Michael, On Wed, 16 Oct 2019 21:32:55 +0900 Takashi Yano wrote: > On Mon, 14 Oct 2019 13:07:22 +0200 > Michael Haubenwallner wrote: > > Actually I do prefer the TERM=dumb behaviour, having the current terminal > > buffer content get redrawn at line 1 when cmd is started only, not when > > running just Cygwin programs. > > > > My real problem is more sophisticated, and boils down to the creation of > > some > > pty's in a row, each having some commands run inside, and I do expect to see > > the output of each command while the series runs and when done, much like: > > > > > > > {some output from previous linux commands} > > > {some output} > > > {some output} > > > haubi@linuxbox ~ $ ssh -t cygwin2016 hostname; hostname; ssh -t > > > cygwin2016 hostname > > > cygwin2016 > > > Connection to cygwin2016 closed. > > > linuxbox > > > cygwin2016 > > > Connection to cygwin2016 closed. > > > haubi@linuxbox ~ $ > > > > Let me consider... I have made a patch for this dilemma and will submit soon. Could you please test? -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
On 10/16/19 4:35 PM, Takashi Yano wrote: > On Mon, 14 Oct 2019 13:07:22 +0200 > Michael Haubenwallner wrote: >>> haubi@linuxbox ~ $ ssh -t cygwin2016 hostname; hostname; ssh -t cygwin2016 >>> hostname > > By the way, why do you specify -t option for ssh? > Without -t option, that will work as you expected. > Using ssh here is just the sample. The real project is the Gentoo Linux package manager named "portage", which does open a PTY for each build task. I'm not into it's details, but my guess is to have more control over some package's build system beyond just redirecting stdin, stdout and stderr. /haubi/ PS: In case you wonder why using a Linux package manager on Cygwin: There is the Gentoo Prefix subproject, that allows to install and manage the Gentoo package set within some directory without the need for chroot or even root permission, on top of any POSIXish platform, not just Linux. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
On Mon, 14 Oct 2019 13:07:22 +0200 Michael Haubenwallner wrote: > > haubi@linuxbox ~ $ ssh -t cygwin2016 hostname; hostname; ssh -t cygwin2016 > > hostname By the way, why do you specify -t option for ssh? Without -t option, that will work as you expected. -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
On Mon, 14 Oct 2019 13:07:22 +0200 Michael Haubenwallner wrote: > Well... even that one is counter intuitive regarding the 'Last login' line. > After login into Cygwin sshd, the 'Last login' line is not shown: > ... > When starting cmd, the terminal does loose colors, and the 'Last login' > line suddenly is shown as first line: This is not as I intended. I will submit a patch for this issue. > Actually I do prefer the TERM=dumb behaviour, having the current terminal > buffer content get redrawn at line 1 when cmd is started only, not when > running just Cygwin programs. > > My real problem is more sophisticated, and boils down to the creation of some > pty's in a row, each having some commands run inside, and I do expect to see > the output of each command while the series runs and when done, much like: > > > > {some output from previous linux commands} > > {some output} > > {some output} > > haubi@linuxbox ~ $ ssh -t cygwin2016 hostname; hostname; ssh -t cygwin2016 > > hostname > > cygwin2016 > > Connection to cygwin2016 closed. > > linuxbox > > cygwin2016 > > Connection to cygwin2016 closed. > > haubi@linuxbox ~ $ > Let me consider... -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
On 10/11/19 11:24 AM, Takashi Yano wrote: > Hi Michael, > > On Thu, 10 Oct 2019 12:43:56 +0200 > Michael Haubenwallner wrote: >> I'm encountering another strange behaviour I do not remember to have seen >> before: >> >> Using ssh from some Linux xterm into the Cygwin sshd running on Server 2019 >> does clear the current terminal content as if /usr/bin/clear was executed. > > This is intentional behaviour. > > The pseudo console has its own screen buffer behind, and redraws > the screen based on the screen buffer at undetermined timing.> The screen > buffer is empty at the beginning, so the screen should > be cleared at the opening of the pty so that the real screen and > the screen buffer are synchronozed. > > The clear screen is prevented when TERM=dumb, so you can see what > happens if clear screen is not done by following steps.> > 1) Execute ls or ps to draw something to screen. > 2) env TERM=dumb ssh > 3) Execute cmd.exe. Well... even that one is counter intuitive regarding the 'Last login' line. After login into Cygwin sshd, the 'Last login' line is not shown: haubi@linuxbox ~ $ ssh cygwin2019 > > haubi@cygwin2019 ~ > $ > > > > > > > When starting cmd, the terminal does loose colors, and the 'Last login' line suddenly is shown as first line: > Last login: Mon Oct 14 12:30:52 2019 from 192.168.56.1 > > haubi@cygwin2019 ~ > $ cmd > Microsoft Windows [Version 10.0.17763.805] > (c) 2018 Microsoft Corporation. All rights reserved. > > C:\cygwin64\home\haubi> > > However, with TERM=dumb, the terminal content is: > {some output from previous linux commands} > {some output} > {some output} > {some output} > {some output} > haubi@linuxbox ~ $ TERM=dumb ssh cygwin2019 > Last login: Mon Oct 14 12:37:24 2019 from 192.168.56.1 > > haubi@cygwin2019 ~ > $ And when cmd was started: > Last login: Mon Oct 14 12:37:24 2019 from 192.168.56.1 > > haubi@cygwin2019 ~ > $ cmd > Microsoft Windows [Version 10.0.17763.805] > (c) 2018 Microsoft Corporation. All rights reserved. > > C:\cygwin64\home\haubi> > > Actually I do prefer the TERM=dumb behaviour, having the current terminal buffer content get redrawn at line 1 when cmd is started only, not when running just Cygwin programs. My real problem is more sophisticated, and boils down to the creation of some pty's in a row, each having some commands run inside, and I do expect to see the output of each command while the series runs and when done, much like: > {some output from previous linux commands} > {some output} > {some output} > haubi@linuxbox ~ $ ssh -t cygwin2016 hostname; hostname; ssh -t cygwin2016 > hostname > cygwin2016 > Connection to cygwin2016 closed. > linuxbox > cygwin2016 > Connection to cygwin2016 closed. > haubi@linuxbox ~ $ And looking at the code actually makes me belive that even emacs does have troubles when the clear screen code is emitted on pty creation... Thanks! /haubi/ (in hope that "embedding the screen shots" does work) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
Hi Michael, On Thu, 10 Oct 2019 12:43:56 +0200 Michael Haubenwallner wrote: > I'm encountering another strange behaviour I do not remember to have seen > before: > > Using ssh from some Linux xterm into the Cygwin sshd running on Server 2019 > does clear the current terminal content as if /usr/bin/clear was executed. This is intentional behaviour. The pseudo console has its own screen buffer behind, and redraws the screen based on the screen buffer at undetermined timing. The screen buffer is empty at the beginning, so the screen should be cleared at the opening of the pty so that the real screen and the screen buffer are synchronozed. The clear screen is prevented when TERM=dumb, so you can see what happens if clear screen is not done by following steps. 1) Execute ls or ps to draw something to screen. 2) env TERM=dumb ssh 3) Execute cmd.exe. -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
Hi Takashi, On 9/22/19 4:11 PM, Ken Brown wrote: > There have been a lot of changes in the PTY code since > cygwin-3.1.0-0.5. Please test! I'm encountering another strange behaviour I do not remember to have seen before: Using ssh from some Linux xterm into the Cygwin sshd running on Server 2019 does clear the current terminal content as if /usr/bin/clear was executed. Even moving /usr/bin/screen away does not make a difference, and it actually does look like creating a new PTY does emit some 'clear screen' TTY code (whatever that exactly is). This does neither happen on Server 2012r2, nor with cygwin-3.0.7 on Server 2019. Thanks! /haubi/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
Hi Michael, Thanks for the report. On Wed, 2 Oct 2019 16:03:53 +0200 Michael Haubenwallner wrote: > * I'm logged into some Server 2012r2 box via Cygwin sshd from Linux xterm, > * export EDITOR=vim # but same problem with EDITOR=emacs > * cd to some git project > * git rebase -i HEAD^ > * Ctrl-Z, to temporarily return to shell prompt > > Both the editor and the git processes seem to be suspended, but the > shell does not react nor show the prompt in any way, although further > keyboard input characters are displayed. I looked into this problem, and found this caused by the following change. > diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc > index 848f9bd68..db0fe0867 100644 > --- a/winsup/cygwin/exceptions.cc > +++ b/winsup/cygwin/exceptions.cc > @@ -949,7 +949,7 @@ _cygtls::interrupt_setup (siginfo_t& si, void *handler, > struct sigaction& siga) >if (incyg) > set_signal_arrived (); > > - if (!have_execed) > + if (!have_execed && ch_spawn.iscygwin ()) > proc_subproc (PROC_CLEARWAIT, 1); >sigproc_printf ("armed signal_arrived %p, signal %d", > signal_arrived, si.si_signo); The cause is that iscygwin() returns false even if the process is cygwin process, contrary to my expectation. However, it is natural if I think well. I have just submitted a patch for this issue. -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
On 10/2/2019 10:03 AM, Michael Haubenwallner wrote: > Hi Takashi, > > On 9/22/19 4:11 PM, Ken Brown wrote: > >> There have been a lot of changes in the PTY code since >> cygwin-3.1.0-0.5. Please test! > > seems there is another issue related to new PTY code: > > * I'm logged into some Server 2012r2 box via Cygwin sshd from Linux xterm, > * export EDITOR=vim # but same problem with EDITOR=emacs > * cd to some git project > * git rebase -i HEAD^ > * Ctrl-Z, to temporarily return to shell prompt > > Both the editor and the git processes seem to be suspended, but the > shell does not react nor show the prompt in any way, although further > keyboard input characters are displayed. I can reproduce this in an ordinary session on Windows 10 (no ssh needed). Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
Hi Takashi, On 9/22/19 4:11 PM, Ken Brown wrote: > There have been a lot of changes in the PTY code since > cygwin-3.1.0-0.5. Please test! seems there is another issue related to new PTY code: * I'm logged into some Server 2012r2 box via Cygwin sshd from Linux xterm, * export EDITOR=vim # but same problem with EDITOR=emacs * cd to some git project * git rebase -i HEAD^ * Ctrl-Z, to temporarily return to shell prompt Both the editor and the git processes seem to be suspended, but the shell does not react nor show the prompt in any way, although further keyboard input characters are displayed. In a different (ssh) session, with 'ps' I can see the 'git' and 'vim' processes to be suspended, as in having a leading 'S': $ ps | grep pty0 S 51349 51348 51346 27448 pty0 197609 14:37:21 /usr/bin/vim S 51346 51176 51346 11280 pty0 197609 14:37:20 /usr/bin/git 51176 51174 51176 39632 pty0 197609 14:26:41 /usr/bin/bash S 51348 51346 51346 30960 pty0 197609 14:37:21 /usr/libexec/git-core/git Resuming these processes with 'kill -CONT 51349 51346 51348' seems to work so far, but when quitting the editor (using :q), the vim process is gone, but both git processes do consume 100% (one single cpu) each, without any further result. Any idea? Thanks! /haubi/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
On 9/26/2019 6:56 AM, Takashi Yano wrote: > On Wed, 25 Sep 2019 21:09:16 +0900 > Takashi Yano wrote: >> On Tue, 24 Sep 2019 17:37:40 + >> Ken Brown wrote: >>> I just noticed a glitch that goes back to the first commit of the new PTY >>> code >>> (commit 169d65a5774acc76ce3f3feeedcbae7405aa9b57): >>> >>> If I run 'setup_x86 -h' in mintty, there's no output. Prior to that >>> commit, the >>> help output is printed, as expected. >> >> I will look into this problem. Please wait a while. > > I have fixed this problem and submitted a patch just now. Confirmed. Thanks. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
On Wed, 25 Sep 2019 21:09:16 +0900 Takashi Yano wrote: > On Tue, 24 Sep 2019 17:37:40 + > Ken Brown wrote: > > I just noticed a glitch that goes back to the first commit of the new PTY > > code > > (commit 169d65a5774acc76ce3f3feeedcbae7405aa9b57): > > > > If I run 'setup_x86 -h' in mintty, there's no output. Prior to that > > commit, the > > help output is printed, as expected. > > I will look into this problem. Please wait a while. I have fixed this problem and submitted a patch just now. -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
Hi Ken, On Tue, 24 Sep 2019 17:37:40 + Ken Brown wrote: > I just noticed a glitch that goes back to the first commit of the new PTY > code > (commit 169d65a5774acc76ce3f3feeedcbae7405aa9b57): > > If I run 'setup_x86 -h' in mintty, there's no output. Prior to that commit, > the > help output is printed, as expected. I will look into this problem. Please wait a while. -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
Hi Takashi, On 9/22/2019 10:11 AM, Ken Brown wrote: > The following packages have been uploaded to the Cygwin distribution > as test releases: > > * cygwin-3.1.0-0.6 > * cygwin-devel-3.1.0-0.6 > * cygwin-doc-3.1.0-0.6 > > This release comes with a couple of new features and quite a few > bug fixes. > > The most interesting changes: [...] > - Support the new pseudo console in PTY. Pseudo console is a new feature >in Windows 10 1809, which provides console APIs on virtual terminal. >With this patch, native console applications can work in Cygwin PTYs. >Courtesy Takashi Yano. I just noticed a glitch that goes back to the first commit of the new PTY code (commit 169d65a5774acc76ce3f3feeedcbae7405aa9b57): If I run 'setup_x86 -h' in mintty, there's no output. Prior to that commit, the help output is printed, as expected. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
On 9/24/2019 3:37 AM, Michael Haubenwallner wrote: > Hi, > > On 9/22/19 4:11 PM, Ken Brown wrote: >> The following packages have been uploaded to the Cygwin distribution >> as test releases: > > so I do have some Azure Pipelines running, which perform an automated > Cygwin setup from scratch before building my pet project there. > > But then, I also do want to autotest cygwin1.dll itself a little, so I want > to use cygwin TEST versions or similar. Because setup.exe does not > support that right now from the commandline, I do use snapshot builds of > cygwin1.dll, because identifying the last snapshot felt easier than > identifying the last test release. > However, I do see the last snapshot dating back to 2019-08-19, which is > rather old compared to test releases seen since then. > > Is there something broken with building snapshots, or is it just not > automated? It's not automated. Corinna is away, and I'm building test releases in her absence. But there's no issue of identifying the latest test release; each time I upload a new one, I remove the previous one. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
Hi, On 9/22/19 4:11 PM, Ken Brown wrote: > The following packages have been uploaded to the Cygwin distribution > as test releases: so I do have some Azure Pipelines running, which perform an automated Cygwin setup from scratch before building my pet project there. But then, I also do want to autotest cygwin1.dll itself a little, so I want to use cygwin TEST versions or similar. Because setup.exe does not support that right now from the commandline, I do use snapshot builds of cygwin1.dll, because identifying the last snapshot felt easier than identifying the last test release. However, I do see the last snapshot dating back to 2019-08-19, which is rather old compared to test releases seen since then. Is there something broken with building snapshots, or is it just not automated? Thanks! /haubi/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)
The following packages have been uploaded to the Cygwin distribution as test releases: * cygwin-3.1.0-0.6 * cygwin-devel-3.1.0-0.6 * cygwin-doc-3.1.0-0.6 This release comes with a couple of new features and quite a few bug fixes. The most interesting changes: - A revamp of the old FIFO code. It should now be possible to open FIFOs multiple times for writing, something the old code failed on. Courtesy Ken Brown. - Support the new pseudo console in PTY. Pseudo console is a new feature in Windows 10 1809, which provides console APIs on virtual terminal. With this patch, native console applications can work in Cygwin PTYs. Courtesy Takashi Yano. There have been a lot of changes in the PTY code since cygwin-3.1.0-0.5. Please test! === What's new: --- - Add 24 bit color support using xterm compatibility mode in Windows 10 1703 or later. Add fake 24 bit color support for legacy console, which uses the nearest color from 16 system colors. - Support pseudo console in PTY. Pseudo console is a new feature in Windows 10 1809, which provides console APIs on virtual terminal. With this patch, native console applications can work in PTYs such as mintty, ssh, gnu screen or tmux. - New APIs: sched_getaffinity, sched_setaffinity, pthread_getaffinity_np, pthread_setaffinity_np, plus CPU_SET macros. - New APIs: dbm_clearerr, dbm_close, dbm_delete, dbm_dirfno, dbm_error, dbm_fetch, dbm_firstkey, dbm_nextkey, dbm_open, dbm_store. What changed: - - FIFOs can now be opened multiple times for writing. Addresses: https://cygwin.com/ml/cygwin/2015-03/msg00047.html https://cygwin.com/ml/cygwin/2015-12/msg00311.html - If a SA_SIGINFO signal handler changes the ucontext_t pointed to by the third parameter, follow it after returning from the handler. - Eliminate a header file name collision with on case insensitive filesystems by reverting back to . - Allow times(2) to have a NULL argument, as on Linux. Addresses: https://cygwin.com/ml/cygwin/2019-09/msg00141.html Bug Fixes - - Fix select() on console in canonical mode. Return after one line is completed, instead of when only one key is typed. - Make console I/O functions thread-safe. - Define missing MSG_EOR. It's unsupported by the underlying Winsock layer so using it in send(2), sendto(2), or sendmsg(2) will return -1 with errno set to EOPNOTSUPP and recvmsg(2) will never return it. - Fix a timerfd deadlock. Addresses: https://cygwin.com/ml/cygwin/2019-06/msg00096.html - Fix sigpending() incorrectly returning signals for unrelated threads. Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00051.html - Fix a hang when opening a FIFO with O_PATH. Addresses: https://cygwin.com/ml/cygwin-developers/2019-06/msg1.html - Don't append ".lnk" when renaming a socket file. Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00139.html - Make tcsetpgrp() return -1 if its argument is negative. Addresses: https://cygwin.com/ml/cygwin/2019-07/msg00166.html - Avoid mistakenly moving a process under debugger control into the process group of the debugger. Addresses a problem visible in GDB 8.1.1, related to https://cygwin.com/ml/cygwin/2019-07/msg00166.html - Return ENOEXEC from execve for arbitrary files only if the files are executable. Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00054.html - Fix off-by-one in environment evaluation leading to an abort. Addresses: https://cygwin.com/ml/cygwin-patches/2019-q3/msg00069.html - Make output of /proc/[PID]/stat consistent with getpriority(). Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00082.html - 64 bit only: Avoid collisions between memory maps created with shmat and Windows datastructures during fork. Addresses: https://cygwin.com/ml/cygwin/2019-08/msg00107.html === Have fun, Ken Brown, on behalf of Corinna -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple