[ANNOUNCEMENT] Updated: wget-1.19.1-2
A new release of wget, 1.19.1-2, will be available soon for download from your favorite mirror, leaving 1.19.1-1 as previous. NEWS: = This is a rebuild, in order to fix CVE-2017-6508 as well as build against libidn2. See also the package documentation in /usr/share/doc/wget/. DESCRIPTION: GNU Wget is a file retrieval utility which can use either the HTTP, HTTPS, or FTP protocols. Wget features include the ability to work in the background while you're logged out, recursive retrieval of directories, file name wildcard matching, remote file timestamp storage and comparison, use of Rest with FTP servers and Range with HTTP servers to retrieve files over slow or unstable connections, support for Proxy servers, and configurability. UPDATE: === To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'wget' from the 'Web' category. DOWNLOAD: = Note that downloads from cygwin.com aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin wget package maintainer For more details on this list (including unsubscription), see: http://sourceware.org/lists.html -- 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: gcc-6.3.0-2 (x86/x86_64)(Test)
On 6/29/2017 7:16 AM, JonY wrote: gcc-6.3.0-2 has been uploaded for Cygwin. It is marked as a test version. JonY, I assume you want some feedback on this. I've been testing gcc-6.3.0-2 with binutils-2.28-3, on both x86 and x86_64, by rebuilding several of my packages. So far I've built texlive, emacs, and icu. There have been no problems, and all builds have passed their test suites. 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: change in wget logfile behavior
[revisiting this thread] On 03/29/2017 08:45 PM, Eric Blake wrote: > On 03/29/2017 08:30 PM, Andrew Schulman wrote: >> Recently, I guess since wget was upgraded to 1.19, whenever I run wget I get >> a >> bonus message on the console: >> >> Redirecting output to ‘wget-log’. >> >> And sure enough, wget creates the file ~/wget-log, which is usually empty. I didn't see anything in NEWS, but the git log includes: commit dd5c549f6af8e1143e1a6ef66725eea4bcd9ad50 Author: losgrandes Date: Fri Oct 21 17:12:58 2016 +0200 Fixes #45790: wget prints it's progress even when background * src/log.c: Use tcgetpgrp(STDIN_FILENO) != getpgrp() to determine when to print to STD* or logfile. Deprecate log_request_redirect_output function. Use different file handles for STD* and logfile, to easily switch between them when changing fg/bg. I didn't do anything special for the just-built 1.19.1-2 released today, but if you are still seeing the issue, is it only when you run 'wget ...&' in the background, or always? Could it be an issue with cygwin's tcgetpgrp(STDIN_FILENO)? >> >> This behavior is annoying, and new. It can be worked around by putting >> >> logfile = /dev/stderr >> >> in /etc/wgetrc. I'm afraid that doing that may violate the intention of what was supposed to be a fix. You may also want to raise the issue upstream. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3
On 04/14/2017 11:33 PM, Steven Penny wrote: > On Thu, 13 Apr 2017 13:48:04, Eric Blake wrote: >> Is it still a problem with pselect, where rebuilding with the same >> configuration as 7.0.1-2 fixes things? I've got some time today to look at building readline, but for the life of me, I can't figure out what I'm supposed to be debugging. You have so many emails saying "see this earlier URL" that I am lost in what you are saying is wrong or how to reproduce it. I'm currently testing with: bash 4.4.12-3 cygwin 2.8.2-1 libreadline7 7.0.3-3 (or self-built) > I'm really not sure how to even >> go about debugging this one, and it's not my highest priority at the >> moment (I've got coreutils 8.27 to build for cygwin, and autoconf 2.70 >> to release upstream). So any help is welcome. > > Ok. I have not gone through the whole commit, as it is huge: > > http://cygwin.com/ml/cygwin/2017-01/msg00204.html > > but I did find something. Using: > >git checkout readline-7.0-alpha~1 > > for the last good commit and: > >git checkout readline-7.0-alpha > > for the first bad commit, I found that the change to the "rl_insert" > function in > "text.c" breaks pasting and Alt codes with "chcp.com 65001". Can you > work with > this? Thanks again for trying to narrow things down. I have recompiled readline locally with optimizations turned off (so it's easier for me to see what's going on), and am set up to run gdb on bash with a given readline executable installed. If you have really narrowed the problem to rl_insert(), that's at least something I can investigate. But where I'm stuck now is what works for you and what you think is wrong. Is this something where I can start bash under mintty, or do I have to start under cmd? Right there, I already see a difference with the two environments. Starting from cmd, I did: c:\cygwin\bin> od -tx1 which displayed Ω ce a9 0z 003 so I did indeed insert GREEK CAPITAL LETTER OMEGA U+03A9. But trying the same thing under a bash session in minty shows: ê 000 c3 aa 0a 003 so that is not the same character. I'm not sure if a code page change is supposed to alter what I see. So I'm back to cmd to try and debug things. Next, I tried: c:\cygwin\bin> .\dash and again got Ω; pressing complains that ./dash: 1: Ω: not found However, when I try: c:\cygwin\bin> .\bash --norc the display shows :\251 and hitting wipes out that display without doing anything. So I _think_ I'm running into the problem you're describing, but want to make sure, since it is different based on whether I started bash from cmd or from mintty. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3
On 07/27/2017 12:08 PM, Eric Blake wrote:
> So I'm back to cmd to try and debug things. Next, I tried:
>
> c:\cygwin\bin> .\dash
>
>
> and again got Ω; pressing complains that ./dash: 1: Ω: not found
To double check things, I started .\dash, typed 'echo $$', then in a
second terminal, typed 'gdb --pid XXX' with the dash pid.
(gdb) b read
(gdb) b select
(gdb) c
then in the first window, typed to get dash back to its input
loop
and the second window hit a breakpoint in read. But that didn't get me
very far:
Thread 1 hit Breakpoint 1, read (fd=0, ptr=0x41b540 , len=1024)
at /usr/src/debug/cygwin-2.8.2-1/winsup/cygwin/syscalls.cc:1118
1118{
(gdb) fin
Run till exit from #0 read (fd=0, ptr=0x41b540 , len=1024)
at /usr/src/debug/cygwin-2.8.2-1/winsup/cygwin/syscalls.cc:1118
[New Thread 628.0x70c]
readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)
Urgh - gdb uses readline, so debugging readline with gdb may prove
harder than planned if I don't time things right. A second time around,
and instead of using fin, I stepped through:
1118 {
(gdb) n
...
(gdb) n
1139 cfd->read (ptr, len);
(gdb) n
[New Thread 736.0x960]
at the point of the new thread, I typed in
the first terminal, which let the read return, and the buffer contents
are correct:
1140 res = len;
(gdb) p len
$1 = 3
(gdb) p/x ((char*)ptr)[0]
$2 = 0xce
(gdb) p/x ((char*)ptr)[1]
$3 = 0xa9
(gdb) p ((char*)ptr)[2]
$4 = '\n'
so whatever dash did, it read a solid block of input from the terminal;
from there, I quit debugging - obviously dash is not doing things
piecemeal, and manages to replay the same output as it just read in
input (when you aren't trying hard to be interactive, life is easy).
>
> However, when I try:
>
> c:\cygwin\bin> .\bash --norc
>
>
> the display shows :\251
Repeating the gdb attach trick, I'm able to catch bash at this
breakpoint, even without hitting , just by typing :
Thread 1 hit Breakpoint 1, read (fd=0, ptr=0x28c013, len=1)
at /usr/src/debug/cygwin-2.8.2-1/winsup/cygwin/syscalls.cc:1118
Notice a difference? dash had the terminal set up in line-oriented
mode, and blindly reads until EOL or until len=1024 is exhausted; bash
has the terminal set up in byte-oriented mode, and is only reading len=1
at a time. So when entering a UTF-8 character to dash, the whole
character lands in the buffer at once, while under bash (presumably, as
I haven't debugged that far yet), bash must reconstruct the Unicode
characters from the individual bytes.
Stepping through the breakpoints on sees 0xce on
the first read, and 0xa9 on the second. But, in between the two read
breakpoints, the first terminal displayed ':'. So the input is still
making it correctly INTO readline; but being munged on the way to
output; and it very much looks like readline's fault rather than
cygwin's. I'm still trying to put breakpoints in the right places (the
call stack at read() points to rl_getc(), from rl_read_key(), from
readline_internal_char()...), but this is at least to let you know how
I'm tackling the issue, in case it helps someone else spot a solution
faster than me by starting from the same information.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3
On Thu, 27 Jul 2017 12:08:53, Eric Blake wrote: I've got some time today to look at building readline, but for the life of me, I can't figure out what I'm supposed to be debugging. You have so many emails saying "see this earlier URL" that I am lost in what you are saying is wrong or how to reproduce it. Thanks for this. Between your 2 emails, youve put a lot on the table. Instead of getting overwhelmed, I will just start my side of the convo by replaying the problem. Then if you need more from me I am happy to help. So, here is an example problem using LATIN SMALL LETTER O WITH DIAERESIS' (U+00F6): $ chcp.com 65001 Active code page: 65001 - Alt 148 outputs nothing - Alt 0246 outputs nothing - Pasting this character does not work $ chcp.com 437 Active code page: 437 - Alt 148 works - Alt 0246 works - Pasting works http://cygwin.com/ml/cygwin/2017-02/msg00014.html Now you might say, why not just use codepage 437? Which is exactly what Corinna did say: http://cygwin.com/ml/cygwin/2017-03/msg00193.html -- 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: gcc-6.3.0-2 (x86/x86_64)(Test)
On 2017-07-28 02:49, Ken Brown wrote:
On 6/29/2017 7:16 AM, JonY wrote:
gcc-6.3.0-2 has been uploaded for Cygwin. It is marked as a test version.
JonY,
I assume you want some feedback on this.
I've been testing gcc-6.3.0-2 with binutils-2.28-3, on both x86 and
x86_64, by rebuilding several of my packages. So far I've built
texlive, emacs, and icu. There have been no problems, and all builds
have passed their test suites.
Ken
gcc 6.3 works fine for me unless I use threads. Any C++ program that
uses std::thread (and worked with the previous gcc) will fail. Simple
example:
#include
#include
void payload() {
std::cout << "Thread\n";
}
int main() {
std::cout << "Start\n";
std::thread t(payload);
t.join();
std::cout << "Done\n";
}
Build and run with:
g++ thread.cpp -o thread && ./thread || echo Fail
This will print Fail, indicating that the executable errored out.
There's no other output. Sorry, I'm not familiar enough with gcc
debugging to narrow down the error further.
Code that uses raw pthreads instead of the C++ API works fine.
(I'm running 64-bit Cygwin on Windows 8.1.)
Ross Smith
--
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: gcc-6.3.0-2 (x86/x86_64)(Test)
On 27/07/2017 23:04, Ross Smith wrote:
On 2017-07-28 02:49, Ken Brown wrote:
On 6/29/2017 7:16 AM, JonY wrote:
gcc-6.3.0-2 has been uploaded for Cygwin. It is marked as a test
version.
JonY,
I assume you want some feedback on this.
I've been testing gcc-6.3.0-2 with binutils-2.28-3, on both x86 and
x86_64, by rebuilding several of my packages. So far I've built
texlive, emacs, and icu. There have been no problems, and all builds
have passed their test suites.
Ken
gcc 6.3 works fine for me unless I use threads. Any C++ program that
uses std::thread (and worked with the previous gcc) will fail. Simple
example:
#include
#include
void payload() {
std::cout << "Thread\n";
}
int main() {
std::cout << "Start\n";
std::thread t(payload);
t.join();
std::cout << "Done\n";
}
Build and run with:
g++ thread.cpp -o thread && ./thread || echo Fail
This will print Fail, indicating that the executable errored out.
There's no other output. Sorry, I'm not familiar enough with gcc
debugging to narrow down the error further.
Code that uses raw pthreads instead of the C++ API works fine.
(I'm running 64-bit Cygwin on Windows 8.1.)
Ross Smith
it works for me on W7-64
./thread || echo "fail"
Start
Thread
Done
$ g++ --version
g++ (GCC) 6.3.0
--
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: libreadline7-7.0.3-3
On 07/27/2017 01:56 PM, Steven Penny wrote: > On Thu, 27 Jul 2017 12:08:53, Eric Blake wrote: >> I've got some time today to look at building readline, but for the life >> of me, I can't figure out what I'm supposed to be debugging. You have >> so many emails saying "see this earlier URL" that I am lost in what you >> are saying is wrong or how to reproduce it. > > Thanks for this. Between your 2 emails, youve put a lot on the table. > Instead > of getting overwhelmed, I will just start my side of the convo by > replaying the > problem. Then if you need more from me I am happy to help. So, here is an > example problem using LATIN SMALL LETTER O WITH DIAERESIS' (U+00F6): > >$ chcp.com 65001 I still don't know your environment (it's really hard to reproduce issues if I don't know the steps to reproduce them). This looks like a bash prompt, but are you running bash inside mintty, or directly in a cmd window? When I first open a mintty window to get bash, I see: $ chcp.com Active code page: 437 and in that environment, typing displays nothing, but hitting then displays: -bash: $'\302\224': command not found which maps to \xc2\x94; I can confirm that with 'od -tx1'. Trying gives a different character (¦), as \xc2\xa6. When I then do $chcp.com 65001 Active code page 65001 I don't see any change in behavior. But if I first open a cmd window, with NO bash in the mix, I see: c:\cygwin\bin> chcp Active code page: 437 where both and output ö, and where 'od -tx1' confirms both sequences produce \xc3\xb6. Then switching code pages: c:\cygwin\bin> chcp 65001 Active code page: 65001 directly typing prints nothing, while 'od -tx1' still shows that it received \xc3\xb6. I have no idea how alt- sequences are mapped to code points (it is not as trivial as a conversion of base to get either the Unicode code-point of 0x96 or to the UTF-8 encoding), but it appears that the input within cmd is the same, while the choice of code page determines what the output will be. I also have no idea why the alt- sequences produce different inputs under cmd than under mintty. So knowing WHAT environment you are using is VITAL to me understanding the results you are seeing. At any rate, I definitely know that U+00F6 is encoded as \xc3\xb6 in UTF-8 (I confirmed that on Linux, with echo $'\xc3\xb6'). I _don't_ know what it is encoded as in Windows code page 437 or 65001. But a quick google later, and I see that for code page 437 (https://en.wikipedia.org/wiki/Code_page_437), ö is at codepoint 0x94 (decimal 148, octal 0224); meanwhile, 0xf6 is equal to decimal 246. Aha - maybe that explains the two alt- sequences under codepage 437: without a leading zero, you are typing the decimal position which looks up the character from the current code page; WITH a leading zero you are directly requesting the decimal encoding of a Unicode character. And trying some other sequences, I note that õ (LATIN SMALL LETTER O WITH TILDE' (U+00F5)) is not part of code page 437; so there is nothing I can type without a leading 0 to print one; conversely, trying which requests the same unicode character displays merely 'o' (apparently U+006f), which, when you lack o-with-tilde, is a reasonable fallback compared to printing nothing at all. Either way, the character requested by the alt-sequence in the cmd window is then transformed by Cygwin into the appropriate UTF-8 input for the tty stdin of the Cygwin child process. Hmm; repeating those sequences under 'od -tx1', when I try , I see something interesting: the moment I press 5 (while still holding alt), the display prints [G; then releasing alt prints o; the transcription is then 000 1b 1b 5b 47 c3 b5 0a which is ESC ESC [ G (hmm - that's the ANSI terminal escape sequence for moving to column 0), followed by the actual Unicode õ, before my ending newline. No idea why that is leaking through to Cygwin to pick up as input. Is windows trying to beep at me to tell me my Unicode request doesn't exist in the current code page? Except that beep is Ctrl-G (U+0007). But when I switch to code page 65001, wikipedia redirects me to UTF-8. So in that code page, presumably all ALT sequences represent themselves, whether or not there is a leading 0? No, experimentation shows otherwise: shows nothing (and not the smiley face from codepage 437); while shows ^B (where ctrl-b really is code point 2). I have no idea WHAT sequence would thus give you ö. > Now you might say, why not just use codepage 437? Which is exactly what > Corinna > did say: > > http://cygwin.com/ml/cygwin/2017-03/msg00193.html Well, obviously, the code page matters to cmd; and I have no idea what alt- sequences do (or are supposed to do) under mintty. So there may STILL be some lingering craziness on what Cygwin itself should do when it recognizes an alt- sequence coming in (if cygwin translates from the current code page to Unicode, where the current code page definitely affects which character is desired);
Re: [ANNOUNCEMENT] Updated: gcc-6.3.0-2 (x86/x86_64)(Test)
On 2017-07-28 09:19, Marco Atzeri wrote:
On 27/07/2017 23:04, Ross Smith wrote:
gcc 6.3 works fine for me unless I use threads. Any C++ program that
uses std::thread (and worked with the previous gcc) will fail. Simple
example:
#include
#include
void payload() {
std::cout << "Thread\n";
}
int main() {
std::cout << "Start\n";
std::thread t(payload);
t.join();
std::cout << "Done\n";
}
Build and run with:
g++ thread.cpp -o thread && ./thread || echo Fail
This will print Fail, indicating that the executable errored out.
There's no other output. Sorry, I'm not familiar enough with gcc
debugging to narrow down the error further.
Code that uses raw pthreads instead of the C++ API works fine.
(I'm running 64-bit Cygwin on Windows 8.1.)
Ross Smith
it works for me on W7-64
./thread || echo "fail"
Start
Thread
Done
$ g++ --version
g++ (GCC) 6.3.0
That's interesting. Maybe I have something wrong with my installation? I
updated the gcc-core, gcc-g++, and libgcc1 packages to the 6.3 test
version; was there something else I needed? (I found those by searching
the installed package list in the Cygwin installer for gcc or g++, and
seeing which ones offered the option of updating to 6.3; there doesn't
seem to be any way of checking what you actually need in a case like this.)
Ross Smith
--
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: gcc-6.3.0-2 (x86/x86_64)(Test)
On 7/27/2017 5:39 PM, Ross Smith wrote:
On 2017-07-28 09:19, Marco Atzeri wrote:
On 27/07/2017 23:04, Ross Smith wrote:
gcc 6.3 works fine for me unless I use threads. Any C++ program that
uses std::thread (and worked with the previous gcc) will fail. Simple
example:
#include
#include
void payload() {
std::cout << "Thread\n";
}
int main() {
std::cout << "Start\n";
std::thread t(payload);
t.join();
std::cout << "Done\n";
}
Build and run with:
g++ thread.cpp -o thread && ./thread || echo Fail
This will print Fail, indicating that the executable errored out.
There's no other output. Sorry, I'm not familiar enough with gcc
debugging to narrow down the error further.
Code that uses raw pthreads instead of the C++ API works fine.
(I'm running 64-bit Cygwin on Windows 8.1.)
Ross Smith
it works for me on W7-64
./thread || echo "fail"
Start
Thread
Done
$ g++ --version
g++ (GCC) 6.3.0
That's interesting. Maybe I have something wrong with my installation? I
updated the gcc-core, gcc-g++, and libgcc1 packages to the 6.3 test
version; was there something else I needed? (I found those by searching
the installed package list in the Cygwin installer for gcc or g++, and
seeing which ones offered the option of updating to 6.3; there doesn't
seem to be any way of checking what you actually need in a case like this.)
Click the test button when running setup. You'll see several other
packages with versions 6.3.0-2, including libstdc++6.
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] Updated: gcc-6.3.0-2 (x86/x86_64)(Test)
On 2017-07-28 09:45, Ken Brown wrote:
On 7/27/2017 5:39 PM, Ross Smith wrote:
On 2017-07-28 09:19, Marco Atzeri wrote:
On 27/07/2017 23:04, Ross Smith wrote:
gcc 6.3 works fine for me unless I use threads. Any C++ program that
uses std::thread (and worked with the previous gcc) will fail. Simple
example:
#include
#include
void payload() {
std::cout << "Thread\n";
}
int main() {
std::cout << "Start\n";
std::thread t(payload);
t.join();
std::cout << "Done\n";
}
Build and run with:
g++ thread.cpp -o thread && ./thread || echo Fail
This will print Fail, indicating that the executable errored out.
There's no other output. Sorry, I'm not familiar enough with gcc
debugging to narrow down the error further.
Code that uses raw pthreads instead of the C++ API works fine.
(I'm running 64-bit Cygwin on Windows 8.1.)
Ross Smith
it works for me on W7-64
./thread || echo "fail"
Start
Thread
Done
$ g++ --version
g++ (GCC) 6.3.0
That's interesting. Maybe I have something wrong with my installation?
I updated the gcc-core, gcc-g++, and libgcc1 packages to the 6.3 test
version; was there something else I needed? (I found those by
searching the installed package list in the Cygwin installer for gcc
or g++, and seeing which ones offered the option of updating to 6.3;
there doesn't seem to be any way of checking what you actually need in
a case like this.)
Click the test button when running setup. You'll see several other
packages with versions 6.3.0-2, including libstdc++6.
Thanks! Yes, turns out I was missing some packages. Everything works
now. Sorry for the false alarm!
Ross Smith
--
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: libreadline7-7.0.3-3
On Thu, 27 Jul 2017 16:37:45, Eric Blake wrote: I still don't know your environment (it's really hard to reproduce issues if I don't know the steps to reproduce them). This looks like a bash prompt, but are you running bash inside mintty, or directly in a cmd window? 1. Clean Cygwin install 2. Start Cygwin.bat 3. My previous email http://cygwin.com/ml/cygwin/2017-07/msg00388.html -- 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
