[ANNOUNCEMENT] (last?) TEST RELEASE: Cygwin 1.7.35-0.5

[ANNOUNCEMENT] (last?) TEST RELEASE: Cygwin 1.7.35-0.5

[Corinna Vinschen]

Hi Cygwin friends and users,


I released another TEST version of the next upcoming Cygwin release.
If all is well, I hope this is the final test version before going
full ninja.

Apart from a few bug fixes, this release introduces the following
changes in terms of chmod and ACL handling.

- Change handling of group permissions if owner SID == group SID.  Now
  the group permissions don't mirror the user permissions anymore, thus
  leading to less hassle with security-conscious applications.

- Allow group SID to be the same as owner SID for "Microsoft Accounts".
  Those have the group in their user token set to the owner SID by
  default.  Drop the workaround to change their primary group to
  "Users".  It's not required anymore due to the aforementioned change.

These changes correspond with the change in 1.7.35-0.4, which is the
major change driving the above ones:

- Since Cygwin 1.7.34, chmod does not always affect the POSIX permission
  mask as returned by stat(2) or printed by ls(1), due to the improved
  POSIX ACL handling.  As a temporary workaround, chmod now checks if
  secondary groups and users in the ACL have more permissions than the
  primary group.  If so, the permissions of the secondary users and
  groups will be reduced according to the mask given by the new primary
  group permissions.  I.e, chmod 600 will remove all permissions from
  the primary group as well as all secondary user and group entries in
  the ACL.

Please report back your experience, especially if you're still suffering
from "slow startup" problems.

====================================================================
If you're not familiar with the new account information handling
introduced in Cygwin 1.7.34, I suggest to read the new documentation
at https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping
====================================================================

Please also note this change of the default settings for db_home,
db_shell, and db_gecos since 1.7.35-0.3:

    db_home: /home/%U
    db_shell: /bin/bash
    db_gecos: <empty>

This means, if you don't set these values in /etc/nsswitch.conf, there's
no reason for Cygwin to access the DC via LDAP.


Other changes in this release:
==============================

- New APIs: cabsl, cimagl, creall, finitel, hypotl, sqrtl.

- Performance improvements of the new account DB handling.

- Fix /proc/cpuinfo multicore info on Intel CPUs.
  Addresses: https://cygwin.com/ml/cygwin-apps/2015-02/msg00077.html
        
- Generate unique inode number for /dev/tty under all circumstances.
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00211.html
        
- Fix handling of PATH search in execlp and other calls to honor mount flags.
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00119.html

- Remove a debug message accidentally printed to the terminal window
  if an application calls fcntl(F_SETFL) erroneously.

- Two regressions in 1.7.34 acl(SETACL, ...):

  - SETACL overwrote the incoming acltent_t array for bookkeeping purposes
    while iterating over its entries.  This broke reusing the acl in the
    calling application (e.g. setfacl).
    Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00304.html

  - SETACL accidentally missed to grant owner FILE_WRITE_ATTRIBUTES access.
    Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00457.html

- Keep SETACL from duplicating user/group deny/allow ACEs if owner SID is
  the same as group SID.

- When creating directories, keep permissions inherited from parent directory
  inheritable, per POSIX 1003.1e.

- 64 bit: Export forgotten symbol __mempcpy.
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00394.html

- 64 bit: Avoid misbehaviour in signal mask computation.
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00665.html

- Avoid data loss on non-blocking pipes after switching back to blocking.
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00575.html

- Fix a potential heap corruption in mkgroup and mkpasswd when enumerating
  Unix users.

- Regression in 1.7.34:  A patch to the pty handling fixing the problem
  reported in https://cygwin.com/ml/cygwin-developers/2014-11/msg00000.html
  was incomplete and lead to undesired buffering in non-canonical mode.
  This should be fixed now.
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00608.html

- Fix signal handling in a few functions.
  Partially addresses: https://cygwin.com/ml/cygwin/2015-02/msg00762.html


To install 32-bit Cygwin use https://cygwin.com/setup-x86.exe
To install 64 bit Cygwin use https://cygwin.com/setup-x86_64.exe

If you're already running a 32 bit version of Cygwin on 64 bit Windows
machines, you can continue to do so.  If you're planning a new install
of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit
Cygwin version, unless you need certain packages not yet available in
the 64 bit release.


Have fun,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
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] (last?) TEST RELEASE: Cygwin 1.7.35-0.5

[Habermann, David (D)]

> Since Cygwin 1.7.34, chmod does not always affect the POSIX permission
>  mask as returned by stat(2) or printed by ls(1), due to the improved
>  POSIX ACL handling.  As a temporary workaround, chmod now checks if

I'm a neophyte regarding this ACL handling stuff.  Here is my usage model, which probably isn't that far from the model for many Cygwin users:  I use Cygwin to process/manage files within the c:\cygwin folder structure, and a very limited number of other folders/files (e.g. /cygdrive/f/backups/...).  I don't require complex security on any of these, and would like to keep things very simple.

1) Are there any ACL records that might be inherited from windows down into my structures (I'm in a corporate environment where the corporation "messes" with many things, so our windows might not be "as out of the box").
2) How can I detect/eliminate any ACLs within my folder structures of interest?

Re: [ANNOUNCEMENT] (last?) TEST RELEASE: Cygwin 1.7.35-0.5

[Andrey Repin]

Greetings, Habermann, David (D)!

>> Since Cygwin 1.7.34, chmod does not always affect the POSIX permission
>>  mask as returned by stat(2) or printed by ls(1), due to the improved
>>  POSIX ACL handling.  As a temporary workaround, chmod now checks if

> I'm a neophyte regarding this ACL handling stuff.  Here is my usage model,
> which probably isn't that far from the model for many Cygwin users:  I use
> Cygwin to process/manage files within the c:\cygwin folder structure, and a
> very limited number of other folders/files (e.g. /cygdrive/f/backups/...). 
> I don't require complex security on any of these, and would like to keep things very simple.

> 1) Are there any ACL records that might be inherited from windows down into
> my structures (I'm in a corporate environment where the corporation "messes"
> with many things, so our windows might not be "as out of the box").

There's no ACL inheritance enabled inside Cygwin root by default, so no.
To your backups folder, the answer depends on your fstab settings.

> 2) How can I detect/eliminate any ACLs within my folder structures of interest?

You better don't.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 27.02.2015, <23:53>

Sorry for my terrible english...


--
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] (last?) TEST RELEASE: Cygwin 1.7.35-0.5

[Denis Excoffier]

On 2015-02-27 18:52, Corinna Vinschen wrote:
> 
> I released another TEST version of the next upcoming Cygwin release.
> 
I have noticed that the behavior of /usr/bin/script is not better than
previously (probably the change resides near
https://cygwin.com/ml/cygwin-cvs/2015-q1/msg00094.html).

For at least several weeks, the behavior was ok, except for the
Return key, which had to be hit several times to take effect. But the
other characters were ok.

Now (after 2015-02-26), only every fourth character that i type
is flushed to the command line, Return key included. For example,
suppose that my command is "abcdefgh": only after i hit the 'd' key
is "abcd" displayed, and only after i hit the 'h' key the
"efgh" is displayed (the command line reads "abcdefgh"); now
i have to hit four times the return key to "enter" the command.

Previously, the fourth-character-delay was probably already there,
but only for the Return key.

Hope this helps.

Regards,

Denis Excoffier.


--
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] (last?) TEST RELEASE: Cygwin 1.7.35-0.5

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

On Feb 28 00:23, Denis Excoffier wrote:
> On 2015-02-27 18:52, Corinna Vinschen wrote:
> > 
> > I released another TEST version of the next upcoming Cygwin release.
> > 
> I have noticed that the behavior of /usr/bin/script is not better than
> previously (probably the change resides near
> https://cygwin.com/ml/cygwin-cvs/2015-q1/msg00094.html).
> 
> For at least several weeks, the behavior was ok, except for the
> Return key, which had to be hit several times to take effect. But the
> other characters were ok.
> 
> Now (after 2015-02-26), only every fourth character that i type
> is flushed to the command line, Return key included. For example,
> suppose that my command is "abcdefgh": only after i hit the 'd' key
> is "abcd" displayed, and only after i hit the 'h' key the
> "efgh" is displayed (the command line reads "abcdefgh"); now
> i have to hit four times the return key to "enter" the command.
> 
> Previously, the fourth-character-delay was probably already there,
> but only for the Return key.

I can't reproduce this.  I started script, script starts my shell, and
then I can type and I see every character I type immediately, including
the ENTER key.  I tried with SHELL set to /bin/tcsh as well as with
/bin/bash.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] (last?) TEST RELEASE: Cygwin 1.7.35-0.5

[Denis Excoffier]

On 2015-02-28 13:13, Corinna Vinschen wrote:
> 
> On Feb 28 00:23, Denis Excoffier wrote:
>> On 2015-02-27 18:52, Corinna Vinschen wrote:
>>> 
>>> I released another TEST version of the next upcoming Cygwin release.
>>> 
>> I have noticed that the behavior of /usr/bin/script is not better than
>> previously (probably the change resides near
>> https://cygwin.com/ml/cygwin-cvs/2015-q1/msg00094.html).
>> 
>> For at least several weeks, the behavior was ok, except for the
>> Return key, which had to be hit several times to take effect. But the
>> other characters were ok.
>> 
>> Now (after 2015-02-26), only every fourth character that i type
>> is flushed to the command line, Return key included. For example,
>> suppose that my command is "abcdefgh": only after i hit the 'd' key
>> is "abcd" displayed, and only after i hit the 'h' key the
>> "efgh" is displayed (the command line reads "abcdefgh"); now
>> i have to hit four times the return key to "enter" the command.
>> 
>> Previously, the fourth-character-delay was probably already there,
>> but only for the Return key.
> 
> I can't reproduce this.  I started script, script starts my shell, and
> then I can type and I see every character I type immediately, including
> the ENTER key.  I tried with SHELL set to /bin/tcsh as well as with
> /bin/bash.
> 
Oops, forgot to mention: it is under xterm only. Under cmd.exe or under
mintty, all is correct.

Denis Excoffier.


--
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] (last?) TEST RELEASE: Cygwin 1.7.35-0.5

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2692 bytes --]

On Feb 28 15:19, Denis Excoffier wrote:
> On 2015-02-28 13:13, Corinna Vinschen wrote:
> > 
> > On Feb 28 00:23, Denis Excoffier wrote:
> >> On 2015-02-27 18:52, Corinna Vinschen wrote:
> >>> 
> >>> I released another TEST version of the next upcoming Cygwin release.
> >>> 
> >> I have noticed that the behavior of /usr/bin/script is not better than
> >> previously (probably the change resides near
> >> https://cygwin.com/ml/cygwin-cvs/2015-q1/msg00094.html).
> >> 
> >> For at least several weeks, the behavior was ok, except for the
> >> Return key, which had to be hit several times to take effect. But the
> >> other characters were ok.
> >> 
> >> Now (after 2015-02-26), only every fourth character that i type
> >> is flushed to the command line, Return key included. For example,
> >> suppose that my command is "abcdefgh": only after i hit the 'd' key
> >> is "abcd" displayed, and only after i hit the 'h' key the
> >> "efgh" is displayed (the command line reads "abcdefgh"); now
> >> i have to hit four times the return key to "enter" the command.
> >> 
> >> Previously, the fourth-character-delay was probably already there,
> >> but only for the Return key.
> > 
> > I can't reproduce this.  I started script, script starts my shell, and
> > then I can type and I see every character I type immediately, including
> > the ENTER key.  I tried with SHELL set to /bin/tcsh as well as with
> > /bin/bash.
> > 
> Oops, forgot to mention: it is under xterm only. Under cmd.exe or under
> mintty, all is correct.

Since when do you see this problem?

I can not reproduce this in mintty, nor in a Cygwin xterm started on a
remote X server running under Linux.  I can reproduce this with a local
xterm started via startxwin.  But, and that's the problem, I can
reproduce it with the current 1.7.35-0.5 test release, with 1.7.34, and
last but not least also with a debug version of the Cygwin DLL in which I
backed out all PTY-related changes since last November.

I'm not sure this is a giveaway, but from that it seems this problem
is not directly related to a Cygwin change in the last months.

So, jturney and I are wondering when exactly you encountered this problem
for the first time.  Did it coincide with a certain Cygwin release,
or a certain X server?  Or new X libs, perhaps?

Anything you can provide to narrow down the potential culprit would be
helpful.


Thanks,
Corinna

P.S.:  Given my findings, I'm not going to treat that as a regression
for the time being.

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Under /bin/script, characters get printed in four-character chunks

[Denis Excoffier]

On 2015-02-28 16:30, Corinna Vinschen wrote:
> 
> On Feb 28 15:19, Denis Excoffier wrote:
>> On 2015-02-28 13:13, Corinna Vinschen wrote:
>>> 
>>> On Feb 28 00:23, Denis Excoffier wrote:
>>>> On 2015-02-27 18:52, Corinna Vinschen wrote:
>>>>> 
>>>>> I released another TEST version of the next upcoming Cygwin release.
>>>>> 
>>>> I have noticed that the behavior of /usr/bin/script is not better than
>>>> previously (probably the change resides near
>>>> https://cygwin.com/ml/cygwin-cvs/2015-q1/msg00094.html).
>>>> 
>>>> For at least several weeks, the behavior was ok, except for the
>>>> Return key, which had to be hit several times to take effect. But the
>>>> other characters were ok.
>>>> 
>>>> Now (after 2015-02-26), only every fourth character that i type
>>>> is flushed to the command line, Return key included. For example,
>>>> suppose that my command is "abcdefgh": only after i hit the 'd' key
>>>> is "abcd" displayed, and only after i hit the 'h' key the
>>>> "efgh" is displayed (the command line reads "abcdefgh"); now
>>>> i have to hit four times the return key to "enter" the command.
>>>> 
>>>> Previously, the fourth-character-delay was probably already there,
>>>> but only for the Return key.
>>> 
>>> I can't reproduce this.  I started script, script starts my shell, and
>>> then I can type and I see every character I type immediately, including
>>> the ENTER key.  I tried with SHELL set to /bin/tcsh as well as with
>>> /bin/bash.
>>> 
>> Oops, forgot to mention: it is under xterm only. Under cmd.exe or under
>> mintty, all is correct.
> 
> Since when do you see this problem?
> 
> I can not reproduce this in mintty, nor in a Cygwin xterm started on a
> remote X server running under Linux.  I can reproduce this with a local
> xterm started via startxwin.  But, and that's the problem, I can
> reproduce it with the current 1.7.35-0.5 test release, with 1.7.34, and
> last but not least also with a debug version of the Cygwin DLL in which I
> backed out all PTY-related changes since last November.
> 
> I'm not sure this is a giveaway, but from that it seems this problem
> is not directly related to a Cygwin change in the last months.
> 
> So, jturney and I are wondering when exactly you encountered this problem
> for the first time.  Did it coincide with a certain Cygwin release,
> or a certain X server?  Or new X libs, perhaps?
> 
> Anything you can provide to narrow down the potential culprit would be
> helpful.
> 
Well. Here is some more inputs.

This is connected with the "min" option of stty. When this occurs,
'stty -a' says '4' for min. If i change into 'stty min 5' the characters
come by chunks of 5.

I had a look into the sources of xterm, xinit, coreutils, tcsh and cygwin and
i definitely don't understand where the 4 comes from. In any case, 4 should not be
the problem, because 'stty min 4' is perfectly legitimate.

The doc of stty says that 'min' (and 'time') are used in case of '-icanon'.
However, i found in fhandler_tty.cc that it seems not to be always the case.
After i applied the following patch:

diff -uNr cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc
--- cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc	2015-03-17 11:42:16.000000000 +0100
+++ cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc	2015-03-24 19:32:42.000000000 +0100
@@ -715,7 +715,7 @@
 
   if (is_nonblocking () || !ptr) /* Indicating tcflush(). */
     time_to_wait = 0;
-  else if ((get_ttyp ()->ti.c_lflag & ICANON))
+  else if (!(get_ttyp ()->ti.c_lflag & ICANON))
     time_to_wait = INFINITE;
   else
     {


and the problem was gone. Let's try an explanation:
the problem is present since "the beginning", at least
since 2000-02-17, see
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_tty.cc;hb=1fd5e000ace55b323124c7e556a7a864b972a5c4,
and recent (2014-11-13) changes in fhandler_tty.cc made it to appear.

Perhaps i'm also completely wrong.

Hoping this will help,

Regards,

Denis Excoffier.
--
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

X server sets VMIN? (was Re: Under /bin/script, characters get printed in four-character chunks)

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3247 bytes --]

On Mar 24 19:59, Denis Excoffier wrote:
> On 2015-02-28 16:30, Corinna Vinschen wrote:
> > I can not reproduce this in mintty, nor in a Cygwin xterm started on a
> > remote X server running under Linux.  I can reproduce this with a local
> > xterm started via startxwin.  But, and that's the problem, I can
> > reproduce it with the current 1.7.35-0.5 test release, with 1.7.34, and
> > last but not least also with a debug version of the Cygwin DLL in which I
> > backed out all PTY-related changes since last November.
> > 
> > I'm not sure this is a giveaway, but from that it seems this problem
> > is not directly related to a Cygwin change in the last months.
> > 
> > So, jturney and I are wondering when exactly you encountered this problem
> > for the first time.  Did it coincide with a certain Cygwin release,
> > or a certain X server?  Or new X libs, perhaps?
> > 
> > Anything you can provide to narrow down the potential culprit would be
> > helpful.
> > 
> Well. Here is some more inputs.
> 
> This is connected with the "min" option of stty. When this occurs,
> 'stty -a' says '4' for min. If i change into 'stty min 5' the characters
> come by chunks of 5.
> 
> I had a look into the sources of xterm, xinit, coreutils, tcsh and cygwin and
> i definitely don't understand where the 4 comes from. In any case, 4 should not be
> the problem, because 'stty min 4' is perfectly legitimate.
> 
> The doc of stty says that 'min' (and 'time') are used in case of '-icanon'.
> However, i found in fhandler_tty.cc that it seems not to be always the case.
> After i applied the following patch:
> 
> diff -uNr cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc
> --- cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc	2015-03-17 11:42:16.000000000 +0100
> +++ cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc	2015-03-24 19:32:42.000000000 +0100
> @@ -715,7 +715,7 @@
>  
>    if (is_nonblocking () || !ptr) /* Indicating tcflush(). */
>      time_to_wait = 0;
> -  else if ((get_ttyp ()->ti.c_lflag & ICANON))
> +  else if (!(get_ttyp ()->ti.c_lflag & ICANON))

No, this is wrong.  You're switching the code for icanon with the
code for -icanon.  -icanon in stty means ICANON is switched off.

I just gave it another try and the behaviour is perfectly valid.

The real problem is that "something" is setting VMIN to 4.  And that's
somehow inside the X server, if I'm not completely wrong:

- If you start an xterm from mintty like this:

    xterm -display :0

  and then call `stty -a' in it, you'll see that min is 1, and then
  script will behave as desired.

- However, if you start xterm from the X server tray icon and then
  call `stty -a' in it, min is set to 4 and script will misbehave.
  If you call `stty min 1' before calling script, script will work
  as expected again.

So, why does the X server (or whatever controls starting applications
from the X server tray icon) set VMIN to 4?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: X server sets VMIN? (was Re: Under /bin/script, characters get printed in four-character chunks)

[Denis Excoffier]

On 2015-03-24 20:53, Corinna Vinschen wrote:
> 
> On Mar 24 19:59, Denis Excoffier wrote:
>> On 2015-02-28 16:30, Corinna Vinschen wrote:
>>> I can not reproduce this in mintty, nor in a Cygwin xterm started on a
>>> remote X server running under Linux.  I can reproduce this with a local
>>> xterm started via startxwin.  But, and that's the problem, I can
>>> reproduce it with the current 1.7.35-0.5 test release, with 1.7.34, and
>>> last but not least also with a debug version of the Cygwin DLL in which I
>>> backed out all PTY-related changes since last November.
>>> 
>>> I'm not sure this is a giveaway, but from that it seems this problem
>>> is not directly related to a Cygwin change in the last months.
>>> 
>>> So, jturney and I are wondering when exactly you encountered this problem
>>> for the first time.  Did it coincide with a certain Cygwin release,
>>> or a certain X server?  Or new X libs, perhaps?
>>> 
>>> Anything you can provide to narrow down the potential culprit would be
>>> helpful.
>>> 
>> Well. Here is some more inputs.
>> 
>> This is connected with the "min" option of stty. When this occurs,
>> 'stty -a' says '4' for min. If i change into 'stty min 5' the characters
>> come by chunks of 5.
>> 
>> I had a look into the sources of xterm, xinit, coreutils, tcsh and cygwin and
>> i definitely don't understand where the 4 comes from. In any case, 4 should not be
>> the problem, because 'stty min 4' is perfectly legitimate.
>> 
>> The doc of stty says that 'min' (and 'time') are used in case of '-icanon'.
>> However, i found in fhandler_tty.cc that it seems not to be always the case.
>> After i applied the following patch:
>> 
>> diff -uNr cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc
>> --- cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc	2015-03-17 11:42:16.000000000 +0100
>> +++ cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc	2015-03-24 19:32:42.000000000 +0100
>> @@ -715,7 +715,7 @@
>> 
>>   if (is_nonblocking () || !ptr) /* Indicating tcflush(). */
>>     time_to_wait = 0;
>> -  else if ((get_ttyp ()->ti.c_lflag & ICANON))
>> +  else if (!(get_ttyp ()->ti.c_lflag & ICANON))
> 
> No, this is wrong.  You're switching the code for icanon with the
> code for -icanon.  -icanon in stty means ICANON is switched off.
> 
> I just gave it another try and the behaviour is perfectly valid.
> 
> The real problem is that "something" is setting VMIN to 4.  And that's
> somehow inside the X server, if I'm not completely wrong:
> 
> - If you start an xterm from mintty like this:
> 
>    xterm -display :0
> 
>  and then call `stty -a' in it, you'll see that min is 1, and then
>  script will behave as desired.
> 
> - However, if you start xterm from the X server tray icon and then
>  call `stty -a' in it, min is set to 4 and script will misbehave.
>  If you call `stty min 1' before calling script, script will work
>  as expected again.
> 
> So, why does the X server (or whatever controls starting applications
> from the X server tray icon) set VMIN to 4?
> 

It seems that this has something to do with tcsh (and not with XWin).
If you arrange your environment in order that the xterm launches /bin/bash
(instead of tcsh), you get min=0 under 'stty -a' and /bin/script behaves
as expected. If afterwards, in such an xterm, you run '/bin/csh -f', you get
min=4.

Consider the following:

diff -uNr tcsh-6.18.01-original/ed.init.c tcsh-6.18.01-patched/ed.init.c
--- tcsh-6.18.01-original/ed.init.c	2006-08-24 22:56:08.000000000 +0200
+++ tcsh-6.18.01-patched/ed.init.c	2015-03-25 15:56:33.000000000 +0100
@@ -65,7 +65,7 @@
 	(uc)CDSWTCH,	(uc)CERASE2,	 (uc)CSTART, 	   (uc)CSTOP,
 	(uc)CWERASE, 	(uc)CSUSP, 	 (uc)CDSUSP, 	   (uc)CREPRINT,
 	(uc)CDISCARD, 	(uc)CLNEXT,	 (uc)CSTATUS,	   (uc)CPAGE,
-	(uc)CPGOFF,	(uc)CKILL2, 	 (uc)CBRK, 	   (uc)CMIN,
+	(uc)CPGOFF,	(uc)CKILL2, 	 (uc)CBRK, 	   (uc)1,
 	(uc)CTIME
     },
     {

In the original code, CMIN is set to CEOF and CEOF is set to Control-D, hence
min=4. With the patch above, all seems to go well. But this does not
explain why the min=4 is not permanent.

Regards,

Denis Excoffier.



--
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: X server sets VMIN? (was Re: Under /bin/script, characters get printed in four-character chunks)

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2342 bytes --]

On Mar 25 16:26, Denis Excoffier wrote:
> On 2015-03-24 20:53, Corinna Vinschen wrote:
> > - However, if you start xterm from the X server tray icon and then
> >  call `stty -a' in it, min is set to 4 and script will misbehave.
> >  If you call `stty min 1' before calling script, script will work
> >  as expected again.
> > 
> > So, why does the X server (or whatever controls starting applications
> > from the X server tray icon) set VMIN to 4?
> > 
> 
> It seems that this has something to do with tcsh (and not with XWin).
> If you arrange your environment in order that the xterm launches /bin/bash
> (instead of tcsh), you get min=0 under 'stty -a' and /bin/script behaves
> as expected. If afterwards, in such an xterm, you run '/bin/csh -f', you get
> min=4.
> 
> Consider the following:
> 
> diff -uNr tcsh-6.18.01-original/ed.init.c tcsh-6.18.01-patched/ed.init.c
> --- tcsh-6.18.01-original/ed.init.c	2006-08-24 22:56:08.000000000 +0200
> +++ tcsh-6.18.01-patched/ed.init.c	2015-03-25 15:56:33.000000000 +0100
> @@ -65,7 +65,7 @@
>  	(uc)CDSWTCH,	(uc)CERASE2,	 (uc)CSTART, 	   (uc)CSTOP,
>  	(uc)CWERASE, 	(uc)CSUSP, 	 (uc)CDSUSP, 	   (uc)CREPRINT,
>  	(uc)CDISCARD, 	(uc)CLNEXT,	 (uc)CSTATUS,	   (uc)CPAGE,
> -	(uc)CPGOFF,	(uc)CKILL2, 	 (uc)CBRK, 	   (uc)CMIN,
> +	(uc)CPGOFF,	(uc)CKILL2, 	 (uc)CBRK, 	   (uc)1,
>  	(uc)CTIME
>      },
>      {
> 
> In the original code, CMIN is set to CEOF and CEOF is set to Control-D, hence
> min=4. With the patch above, all seems to go well. But this does not
> explain why the min=4 is not permanent.

Thanks for looking into that.  I'm not sure either why this doesn't
occur all the time, but the culprit seems to be this snippet in
ed.term.h:

  #ifndef CMIN
  # define CMIN          CEOF
  #endif /* CMIN */

The default value for CEOF is '\4'.  And no header on Cygwin defines
CMIN, so this looks like two bugs in one (buy one, get one free).

Per `git blame' this code in tcsh is from 1991, so maybe we have two
20th century bugs here.

I'll ask the tcsh maintainer and add a definition for CMIN to 1 (as on
Linux) to the headers for the next Cygwin version.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]