[ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)

[ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)

[Ken Brown]

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 <X11/XLocale.h> on case
  insensitive filesystems by reverting <xlocale.h> back to <sys/_locale.h>.

- 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/msg00001.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

Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)

[Michael Haubenwallner]

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

Re: [ANNOUNCEMENT] cygwin 3.1.0-0.6 (TEST)

[Ken Brown]

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)

[Ken Brown]

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)

[Takashi Yano]

Hi Ken,

On Tue, 24 Sep 2019 17:37:40 +0000
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 <takashi.yano@nifty.ne.jp>

--
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)

[Takashi Yano]

On Wed, 25 Sep 2019 21:09:16 +0900
Takashi Yano wrote:
> On Tue, 24 Sep 2019 17:37:40 +0000
> 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 <takashi.yano@nifty.ne.jp>

--
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)

[Ken Brown]

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 +0000
>> 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)

[Michael Haubenwallner]

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)

[Ken Brown]

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)

[Takashi Yano]

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 <takashi.yano@nifty.ne.jp>

--
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)

[Michael Haubenwallner]

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)

[Takashi Yano]

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 <cygwin-hostname>
3) Execute cmd.exe.

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

--
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)

[Michael Haubenwallner]

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 <cygwin-hostname>
> 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)

[Takashi Yano]

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 <takashi.yano@nifty.ne.jp>

--
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)

[Takashi Yano]

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 <takashi.yano@nifty.ne.jp>

--
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)

[Michael Haubenwallner]

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)

[Takashi Yano]

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 <takashi.yano@nifty.ne.jp>

--
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