Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Brian Inglis]

On 2017-02-06 12:46, Thomas Wolff wrote:
> Am 05.02.2017 um 21:36 schrieb Brian Inglis:
>> On 2017-02-05 11:35, Thomas Wolff wrote:
>>> Am 04.02.2017 um 17:13 schrieb Achim Gratz:
 Thomas Wolff writes:
> I have uploaded mintty 2.7.4 with the following changes:
 Since about November/December last year I'm having problems with
 screen and tmux sessions in mintty not correctly refreshing and
 leaving garbage characters displayed in the terminal. It seems that
 the terminal size is not always correctly reported, especially if
 you make the window occupy the left or right half of the screen via
 Windows shortcut.
>>> Is this within tmux or after leaving tmux (see comment below)? It
>>> would be help to cross-test this; if it's mintty, which version
>>> would show the behaviour first? What happens in xterm?
 Additionally, there seems to be an off-by-one bug when the last
 line of the terminal needs to be scrolled up in order to show
 content that is longer than the remaining width. This happens when
 you for instance recall a long command from history. It's hard to
 see what exactoly happens, but it looks like the one character too
 many gets printed (and wraps onto the next line) before the whole
 terminal window gest scrolled up and the rest of the command gets
 printed in the line below the single wrapped character. That
 remainder is in various states of disarray, showing both remnants
 from the original prompt on the last line (now three lines up),
 empty /spaces where there should have been characters from the
 command and then of course parts of the command.
>>> This might be related to some issue with terminal geometry as
>>> perceived by the shell (see
>>> https://github.com/mintty/mintty/issues/377#issuecomment-137728631).
>>> Have you checked that? Recently changed your prompt? Try with basic
>>> prompt (PS1="\w> ") please.
>> Thanks for supporting and enhancing mintty to be even better in
>> Cygwin, and able to be used as a console for other environments.
>> The test below may be relevant to the above problem, or may be
>> unrelated.
>> Running vttest 2.7 (20140305)
>> http://invisible-island.net/vttest/vttest.html
>> updated by and used by xterm maintainer for testing.
>> Test 1. Test of cursor movements screens 3 80 col mode and 4 132 col
>> mode gives results looking like below ...
> I was aware this test fails, but save any related bug reports so far
> I had assumed it would not be relevant for applications...
> Actually, urxvt (rxvt-unicode as invoked on cygwin) fails the same
> test in the same way, so @Achim: can you please retest with urxvt,
> for some additional diagnostic information?

vttest site documents xterm implements VT100 am/xenl compatibly 
and rxvt and some other consoles do not: ignoring non-print characters 
and sequences until a printable character advances to the next row: 
see:

http://invisible-island.net/vttest/vttest-wrap.html

> Actually, also xterm would fail this test if vttest would not disable
> Reverse Wraparound mode initially.
> It also enables Wraparound mode which again affects the test case.
> Mintty does not support Reverse Wraparound mode disabling, it's
> always implicitly enabled. I could try to change that, however, I'm
> not sure yet that's really the cause.
> Also, the "proper" way to handle wraparound situations (in the 4
> combinations of the 2 modes) is not completely clear, and Reverse
> Wraparound is an xterm specific mode which did not exist on the DEC
> terminals. See some links for reference:
> bash - An obscure one: Documented VT100 'soft-wrap' escape sequence?
> - Stack Overflow
http://stackoverflow.com/questions/31360385/an-obscure-one-documented-vt100-soft-wrap-escape-sequence#31360700
> XTerm – Frequently Asked Questions (FAQ)
> http://invisible-island.net/xterm/xterm.faq.html#vt100_wrapping

My last remaining VT ref seems to be (c) 1987 June DEC EK-VT320-UG-001 
VT320 UG which says on pp.23-24:

"Table 4-4  Display Set-Up Features
Feature Settings*   Function
...
Auto Wrap   Selects whether on not text automati-
cally wraps to the next line when you 
reach the right margin.

*No Auto Wrap*  When the cursor reaches the margin,
the VT320 displays each new charac-
ter/
/
Auto Wrap   *No Auto Wrap*  in the last column of the line. Each
(cont)  (cont)  new character overwrites the previous
character.

Auto Wrap   When the cursor reaches the margin,
the VT320 displays new characters on
the next line.
...
* Default settings are in *bold* type."

[The visual effect of characters "piling up" on the right margin when 
sending 132 character lines at low speed to 

cygpath -w converts relative paths to absolute windows paths

[Roger Qiu]

Hi,

I've found that `cygpath --windows '../` will give back an absolute 
windows path.


I thought this would only happen if you provide the `--absolute` flag, 
or when the path is a special cygwin path.


But this occurs just for normal directories.

I have come across a situation where I need to convert ntfs symlinks to 
unix symlinks and back. Sometimes these symlinks have relative paths 
them. Now by using cygpath --windows, I get back absolute paths, which 
means the integrity of the symlink isn't preserved.


Can `cygpath --windows '../directory'` give back `..\directory` for 
paths aren't special cygwin paths? These relative backslashes are 
supported in Windows right now.


Thanks,

Roger

--
https://github.com/CMCDragonkai
+61420925975


--
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] Updated: mintty 2.7.4

[Doug Henderson]

On 6 February 2017 at 12:46, Thomas Wolff wrote:
> Am 05.02.2017 um 21:36 schrieb Brian Inglis:
>>
>> On 2017-02-05 11:35, Thomas Wolff wrote:
>>>
>>> Hi Achim,
>>>
>>> Am 04.02.2017 um 17:13 schrieb Achim Gratz:

 Thomas Wolff writes:
>
> I have uploaded mintty 2.7.4 with the following changes:

This may be a whisper from the distant past when some glass ttys moved
the cursor to the next line when you wrote to the last column of a
line, and others did not move the cursor until you wrote the next
character. Or they were different depend the width mode: 80 or 132
characters.

A virtual terminal handler, such as curses, had to know which behavior
would occur on the physical terminal in order to correctly maintain
the virtual terminal cursor position. When you did not know what the
physical terminal would do, you had to avoid writing to the 80th
column, or use safe cursor positioning that would work in either case.

Back in the day, I wrote a full screen editor that was usable with a
luggable glass tty with a 300 baud acoustic modem. Optimizing the data
stream was an extreme priority.

I also enhanced the terminal emulator that came with Plan 9 to more
fully emulate DEC's VT100 family of physical terminals when connected
to various remote mini's and mainframes running full screen apps.

When you don't know the precise behavior of a terminal or terminal
emulator, you must fallback to "safe" defaults. You can't always trust
the TERM variable. If you're lucky, you will get a standard
answer-back, which, in the case of a terminal emulator, may be
faithfully emulated.

Programs like screen and tmux throw themselves into the middle of this muddle.

HTH or at least entertained
Doug

-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com

--
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] Updated: mintty 2.7.4

[Thomas Wolff]

Am 05.02.2017 um 21:36 schrieb Brian Inglis:

On 2017-02-05 11:35, Thomas Wolff wrote:

Hi Achim,

Am 04.02.2017 um 17:13 schrieb Achim Gratz:

Thomas Wolff writes:

I have uploaded mintty 2.7.4 with the following changes:

Since about November/December last year I'm having problems with
screen and tmux sessions in mintty not correctly refreshing and
leaving garbage characters displayed in the terminal. It seems that
the terminal size is not always correctly reported, especially if
you make the window occupy the left or right half of the screen via
Windows shortcut.

Is this within tmux or after leaving tmux (see comment below)? It
would be help to cross-test this; if it's mintty, which version
would show the behaviour first? What happens in xterm?

Additionally, there seems to be an off-by-one bug when the last
line of the terminal needs to be scrolled up in order to show
content that is longer than the remaining width. This happens when
you for instance recall a long command from history. It's hard to
see what exactoly happens, but it looks like the one character too
many gets printed (and wraps onto the next line) before the whole
terminal window gest scrolled up and the rest of the command gets
printed in the line below the single wrapped character. That
remainder is in various states of disarray, showing both remnants
from the original prompt on the last line (now three lines up),
empty /spaces where there should have been characters from the
command and then of course parts of the command.

This might be related to some issue with terminal geometry as
perceived by the shell (see
https://github.com/mintty/mintty/issues/377#issuecomment-137728631).
Have you checked that? Recently changed your prompt? Try with basic
prompt (PS1="\w> ") please.

Thanks for supporting and enhancing mintty to be even better in
Cygwin, and able to be used as a console for other environments.

The test below may be relevant to the above problem, or may be
unrelated.
Running vttest 2.7 (20140305)
http://invisible-island.net/vttest/vttest.html
updated by and used by xterm maintainer for testing.

Test 1. Test of cursor movements screens 3 80 col mode and 4 132 col
mode gives results looking like below ...
I was aware this test fails, but save any related bug reports so far I 
had assumed it would not be relevant for applications...
Actually, urxvt (rxvt-unicode as invoked on cygwin) fails the same test 
in the same way, so
@Achim: can you please retest with urxvt, for some additional diagnostic 
information?
Actually, also xterm would fail this test if vttest would not disable 
Reverse Wraparound mode initially.
It also enables Wraparound mode which again affects the test case. 
Mintty does not support Reverse Wraparound mode disabling, it's always 
implicitly enabled. I could try to change that, however, I'm not sure 
yet that's really the cause.
Also, the "proper" way to handle wraparound situations (in the 4 
combinations of the 2 modes) is not completely clear, and Reverse 
Wraparound is an xterm specific mode which did not exist on the DEC 
terminals. See some links for reference:
bash - An obscure one: Documented VT100 'soft-wrap' escape sequence? - 
Stack Overflow 


http://stackoverflow.com/questions/31360385/an-obscure-one-documented-vt100-soft-wrap-escape-sequence#31360700
XTerm – Frequently Asked Questions (FAQ) 


http://invisible-island.net/xterm/xterm.faq.html#vt100_wrapping
VT100 Termcap Entry (CENG 455) 


http://www.pitt.edu/%7Ejcaretto/text/cleanup/vt100-termcap.html


It may also be useful if mintty had some character hex value box
display mode switch to display the actual codes at each visual
position, or maybe a font used to display the character hex value in
a box, often used in fonts as glyphs for non-printing control
characters and those in the Private Use Area, in which case that could
perhaps be added to the mintty package for use in testing.
I have been searching for such a font with no success so far.
Hmm, I don't see how that's related to this issue, but it might be a 
nice feature.
Like my text editor, mined, actually does: inform about current 
character code and name (and CJK details if desired).
I could imagine to have a mode (switchable by context menu) that shows 
this information in the window title bar, to avoid the effort of 
handling a popup box.


--
Thomas

--
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] Updated: mintty 2.7.4

[Thomas Wolff]

Am 06.02.2017 um 20:16 schrieb Achim Gratz:

Achim Gratz writes:

Thomas Wolff writes:

Is this within tmux or after leaving tmux (see comment below)? It
would be help to cross-test this; if it's mintty, which version would
show the behaviour first? What happens in xterm?

Within tmux or more often screen within tmux.  I'll have to try what
happens in plain mintty.

OK, it's more… interesting than I first thought.  I can reproduce it
when setting up a screen session inside tmux and I might need to be
connected to the screen session via mosh.  It doesn't consistently
happen even then.  I first thought it had something to do with my
setting TERM to xterm-256color, but it happens with screen-256color as
well.  I've had the issue appear when switching the TERM variable to
xterm-256color and it didn't go away when I've reverted to
screen-256color.  I've meanwhile confirmed I get the same problem when
I'm running under screen-256color all the way from the first shell.

Why would you want to run screen within tmux?
Anyway, I cannot reproduce the issue, although I used to have strange 
effects with a remote screen or tmux once myself.
I'd either need a reproducible test case (like start a fresh mintty, run 
screen (locally/remotely?), type a certain command etc),
or, likely easier in this case, a screen log that demonstrates the 
effect (mintty -l logfile).
You may also try to toggle wraparound mode; see the mail I'm going to 
write in response to Brian's response.



No, I don't think it's related to that issue and I haven't changed my
prompt in years.  It's specifically happening only on the last line in
the terminal window with the first character that should wrap onto the
next line and not anywhere else and only when scrolling the window
happens.  If the shell has lost the correct terminal geometry, then it's
wrong on all lines of the terminal, not just the last in my experience.

I can actually provoke this by simply typing in a too long line: when
the last character in the last line gets entered, the terminal opens a
new line below, scrolling the content up one line (and keeping the
status line of the tmux in place on the _real_ last line).  It then
scrolls up another line, repeats the the first character of the prompt
on the original line and appends any further characters entered after
that character.
See above. This might have helped already but it didn't. More precise 
reproduction instructions are needed.

--
Kind regards
Thomas

--
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: perl-DateTime et.al.

[Achim Gratz]

Yaakov Selkowitz writes:
> I have given you joint maintainership of most of the Perl packages.

Thanks.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Achim Gratz]

Achim Gratz writes:
> Thomas Wolff writes:
>> Is this within tmux or after leaving tmux (see comment below)? It
>> would be help to cross-test this; if it's mintty, which version would
>> show the behaviour first? What happens in xterm?
>
> Within tmux or more often screen within tmux.  I'll have to try what
> happens in plain mintty.

OK, it's more… interesting than I first thought.  I can reproduce it
when setting up a screen session inside tmux and I might need to be
connected to the screen session via mosh.  It doesn't consistently
happen even then.  I first thought it had something to do with my
setting TERM to xterm-256color, but it happens with screen-256color as
well.  I've had the issue appear when switching the TERM variable to
xterm-256color and it didn't go away when I've reverted to
screen-256color.  I've meanwhile confirmed I get the same problem when
I'm running under screen-256color all the way from the first shell.

> No, I don't think it's related to that issue and I haven't changed my
> prompt in years.  It's specifically happening only on the last line in
> the terminal window with the first character that should wrap onto the
> next line and not anywhere else and only when scrolling the window
> happens.  If the shell has lost the correct terminal geometry, then it's
> wrong on all lines of the terminal, not just the last in my experience.

I can actually provoke this by simply typing in a too long line: when
the last character in the last line gets entered, the terminal opens a
new line below, scrolling the content up one line (and keeping the
status line of the tmux in place on the _real_ last line).  It then
scrolls up another line, repeats the the first character of the prompt
on the original line and appends any further characters entered after
that character.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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: Console buffer width always 1 column less than setting

[Marco Atzeri]

On 06/02/2017 18:43, Lee Dilkie wrote:



On 2/5/2017 3:59 PM, Steven Penny wrote:

On Sun, 5 Feb 2017 14:12:04, Vince Rice wrote:

On Feb 5, 2017, at 1:53 PM, Steven Penny  wrote:


Please fix your email client. You should not be quoting people’s email
directly.



that's just silly. Anyone with access to this public list has your email
address when you posted.

The guy was just trying to help you with your issue, and you come across
as a dork.

-lee



the problem is that  email address in clear will be reported on the
web archive and  will be easy accessible to spam bot looking
for email address.

It is specifically mentioned on:
https://cygwin.com/lists.html

see as example:
https://web.archive.org/web/20090917075216/http://www.cdt.org/speech/spam/030319spamreport.shtml

Regards
Marco

--
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: Console buffer width always 1 column less than setting

[Vince Rice]

> On Feb 6, 2017, at 11:43 AM, Lee Dilkie wrote:
> 
> On 2/5/2017 3:59 PM, Steven Penny wrote:
>> On Sun, 5 Feb 2017 14:12:04, Vince Rice wrote:
 On Feb 5, 2017, at 1:53 PM, Steven Penny  wrote:
>> 
>> Please fix your email client. You should not be quoting people’s email 
>> directly.
>> 
> 
> that's just silly. Anyone with access to this public list has your email 
> address when you posted.
> 
> The guy was just trying to help you with your issue, and you come across as a 
> dork.

The rules on this list are to not quote email addresses, I just missed it when 
I posted.
Anyone subscribed to the list may have it, but we don't want them the archives 
for a bot to go through and harvest.
Which may or may not affect your opinion…
--
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: Console buffer width always 1 column less than setting

[Lee Dilkie]

On 2/5/2017 3:59 PM, Steven Penny wrote:

On Sun, 5 Feb 2017 14:12:04, Vince Rice wrote:

On Feb 5, 2017, at 1:53 PM, Steven Penny  wrote:


Please fix your email client. You should not be quoting people’s email directly.



that's just silly. Anyone with access to this public list has your email 
address when you posted.

The guy was just trying to help you with your issue, and you come across as a 
dork.

-lee

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

[newlib-cygwin] Make anchors stable in generated Cygwin HTML documentation

[Jon TURNEY]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=4e46ff3e8198adc00bbf4b4455c760ff0c599f44

commit 4e46ff3e8198adc00bbf4b4455c760ff0c599f44
Author: Jon Turney 
Date:   Sat Jan 7 20:21:59 2017 +

Make anchors stable in generated Cygwin HTML documentation

Give more elements ids, so random ids aren't assigned to them, so anchors
are stable between builds.

Signed-off-by: Jon Turney 

Diff:
---
 winsup/doc/logon-funcs.xml |  8 ++---
 winsup/doc/misc-funcs.xml  |  6 ++--
 winsup/doc/path.xml| 22 ++--
 winsup/doc/utils.xml   | 90 +++---
 4 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/winsup/doc/logon-funcs.xml b/winsup/doc/logon-funcs.xml
index 084b0c7..31da4be 100644
--- a/winsup/doc/logon-funcs.xml
+++ b/winsup/doc/logon-funcs.xml
@@ -29,7 +29,7 @@
 
   
 
-  
+  
 Description
 Given a pointer to a passwd entry of a user and a cleartext password,
 returns a HANDLE to an impersonation token for this user which can be used
@@ -38,7 +38,7 @@ to impersonate that user.  This function can only be called 
from a process
 which has the required NT user rights to perform a logon.
   
 
-  
+  
 See also
 See also the chapter
 Switching the 
user context
@@ -71,7 +71,7 @@ in the Cygwin User's guide.
 
   
 
-  
+  
 Description
 Use this function to enable the token given as parameter as
 impersonation token for the next call to setuid or
@@ -81,7 +81,7 @@ impersonation token for the next call to 
setuid or
 password authentication.
   
 
-  
+  
 See also
 See also the chapter
 Switching the 
user context
diff --git a/winsup/doc/misc-funcs.xml b/winsup/doc/misc-funcs.xml
index 16b3d61..7463942 100644
--- a/winsup/doc/misc-funcs.xml
+++ b/winsup/doc/misc-funcs.xml
@@ -32,7 +32,7 @@
 
   
 
-  
+  
 Description
 This function can be used to turn a Win32 "handle" into a
 posix-style file handle. fd may be -1 to
@@ -70,7 +70,7 @@ much.
 
   
 
-  
+  
 Description
 This function gives you access to various internal data and functions.
 It takes two arguments.  The first argument is a type from the 
'cygwin_getinfo_types'
@@ -103,7 +103,7 @@ enum.  The second is an optional pointer.
 
   
 
-  
+  
 Description
  Outputs a stackdump to stderr from the called location.
 
diff --git a/winsup/doc/path.xml b/winsup/doc/path.xml
index 81d4c3f..f56614b 100644
--- a/winsup/doc/path.xml
+++ b/winsup/doc/path.xml
@@ -31,7 +31,7 @@
 
   
 
-  
+  
 Description
 Use this function to convert POSIX paths in
 from to Win32 paths in to
@@ -75,9 +75,9 @@ error and errno is set to one of the below values.
 
   
 
-  
+  
 Example
-
+
 Example use of cygwin_conv_path
 
 

Re: [PATCH] Make anchors stable in generated Cygwin HTML documentation

[Corinna Vinschen]

On Feb  5 13:45, Jon Turney wrote:
> Give more elements ids, so random ids aren't assigned to them, so anchors
> are stable between builds.

ACK,
Corinna

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


signature.asc
Description: PGP signature

Re: Problems with ssh-host-config on Windows 10

[Erik Bray]

On Thu, Feb 2, 2017 at 2:08 PM, Corinna Vinschen
 wrote:
> On Feb  2 12:19, Erik Bray wrote:
>> Hi all,
>>
>> I've been trying to get a Cygwin sshd server running on a Windows 10
>> VM, and have found it to be surprisingly tricky without some
>> additional fiddling, and it's not clear to me whether that's expected
>> or if it's a bug.  I've attached the cygcheck output from the VM.
>>
>> The symptom I've having seems to be the same as in this post:
>>
>> https://cygwin.com/ml/cygwin/2015-06/msg00265.html
>>
>> The problem seems to be stemming from some assumptions in:
>> /usr/share/csih/cygwin-service-installation-helper.sh
>>
>> It creates the "privileged user" (in my case with the default name
>> cyg_server) with `net user`, including the SAM comment entry:
>>
>> /comment:''
>>
>> Shortly after it calls:
>>
>> passwd -e "${csih_PRIVILEGED_USERNAME}"
>>
>> and this fails with:
>>
>> Warning: Setting password expiry for user 'desktop-mk2koav+cyg_server' 
>> failed!
>>
>> This happens because this is a fresh Cygwin install with all the
>> default settings in /etc/nsswitch.conf.  In particular, no passwd
>> entry is found for the cyg_server user unless I explicitly add "local"
>> to db_enum.  Furthermore, the SAM comment entry is not read correctly
>> without db_home: desc and db_shell: desc.  In summary, I had to edit
>> /etc/nsswitch.conf to:
>>
>> passwd db
>> db_enum: local
>> db_home: desc
>> db_shell: desc
>
> The assumption in ssh-host-config is that your nsswitch.conf settings
> are already correct.  It's kind of tricky to set up accounts and stuff
> in a not yet configured environment.

I think that's reasonable, but the question is what is "correct"?  Any
valid settings for nsswitch.conf could be "correct" for different use
cases, whereas the cygwin-service-installation-helper.sh script seems
to have some very specific requirements that don't match the default
configuration, or even many non-default configurations (especially
w.r.t. db_home and db_shell).

Best,
Erik

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