How to write to shared memory?
Hi, I have a bash loop which I have significantly sped up by using: for ((i=0;i=Z;i++)); do echo $i; done instead of other format for loops as well as using internal math like: NEWX=$(($EAST+$DX)) Instead of let or expr. This process is now heaps faster but I want to echo the data to a file but not have to write to a file on each loop cycle as it slows it down. On native linux you would write: echo $NEWX /dev/shm/new and then at the end of all the loops at the end of the script write to a file with: cat /dev/shm/new $OUT -- Finally to the question. How do you do this with Cygwin?? Cheers, Barrett. -- 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: How to write to shared memory?
On 2010-10-20 08:21 , Cameron, Barrett wrote: Hi, I have a bash loop which I have significantly sped up by using: for ((i=0;i=Z;i++)); do echo $i; done Does for ((i=0;i=Z;i++)); do echo $i; done $OUT Help? It at least avoids reopening the file every time. instead of other format for loops as well as using internal math like: NEWX=$(($EAST+$DX)) Instead of let or expr. This process is now heaps faster but I want to echo the data to a file but not have to write to a file on each loop cycle as it slows it down. On native linux you would write: echo $NEWX /dev/shm/new and then at the end of all the loops at the end of the script write to a file with: cat /dev/shm/new $OUT -- Finally to the question. How do you do this with Cygwin?? Cheers, Barrett. -- 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 -- 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
TCL and Cygwin 1.7 symlinks
I know that Cywin TCL is not a 'real' Cygwin port, but I've noticed the following behaviour: $ cd /tmp $ mkdir x1 $ mkdir x1/foo $ echo abc x1/foo/bar $ mkdir x2 $ cd x2 $ ln -s ../x1/foo $ cat foo/bar abc $ tclsh % file normalize foo C:/Cygwin/tmp/x1/foo % file readlink foo could not readlink foo: invalid argument % exit $ readlink foo ../x1/foo There are three inconsistencies here: - TCL 'file readlink' fails. Fair enough, if the Cygwin TCL build doesn't understand Cygwin 1.7 symlinks (as suggested by the TCL FAQ 4.45). - But TCL 'file normalize' is successfully resolving the symlink! - Doublebut TCL 'file normalize' is not meant to resolve a symlink at the end of a path. The normalized path should be 'C:/Cygwin/tmp/x2/foo'. What's going on? Jeremy -- 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: Sending signals to a subprocess
On 10/20/2010 1:09 AM, Andy Koppe wrote:
On 20 October 2010 04:17, Ken Brownkbr...@cornell.edu wrote:
Emacs creates a subprocess that runs an interactive bash shell. Emacs wants
to get the PGID of the foreground process group associated to the tty of
this shell, and it does this on Linux via TIOCGPGRP (or equally well
tcgetpgrp). I think it uses the file descriptor of the master of the pty
for this purpose. If you (or some other programmer reading this) could give
me the code for setting all this up, I could play with it and try to figure
out why I'm seeing a difference between Linux and Cygwin here. I just don't
know how to create a subprocess, give it a terminal, etc.
Here's a test along those lines that does show a difference between
Linux and Cygwin:
#includestdio.h
#includepty.h
int main(void)
{
int pid, fd;
pid = forkpty(fd, 0, 0, 0);
if (!pid)
sleep(2);
else {
sleep(1);
printf(pid=%i fd=%i pgrp=%i\n, pid, fd, tcgetpgrp(fd));
}
}
Thanks, Andy. I had no idea how to do this.
On Linux, where it requires -lutil to link, this gives:
pid=13308 fd=3 tcgetpgrp(fd)=13308
I can confirm this on my Linux system. I mention this because
apparently tcgetpgrp isn't the same on all Linux systems. See below.
On Cygwin:
pid=268 fd=3 tcgetpgrp(fd)=0
Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because
she saw Linux doing that. But when I run Corinna's test on my Linux
system, I get -1 where she got 0. So not all Linuxes agree on what
tcgetpgrp should do.
Neither of those looks POSIX-compliant to me, because tcgetpgrp should
return -1 since fd 3 isn't the controlling terminal of the calling
process, but the Linux behaviour is rather useful. Perhaps they
decided to apply that restriction only to the slave side?
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: Sending signals to a subprocess
On 20 October 2010 12:21, Ken Brown wrote:
On 10/20/2010 1:09 AM, Andy Koppe wrote:
Emacs creates a subprocess that runs an interactive bash shell. Emacs
wants
to get the PGID of the foreground process group associated to the tty of
this shell, and it does this on Linux via TIOCGPGRP (or equally well
tcgetpgrp). I think it uses the file descriptor of the master of the pty
for this purpose. If you (or some other programmer reading this) could
give
me the code for setting all this up, I could play with it and try to
figure
out why I'm seeing a difference between Linux and Cygwin here. I just
don't
know how to create a subprocess, give it a terminal, etc.
Here's a test along those lines that does show a difference between
Linux and Cygwin:
#includestdio.h
#includepty.h
int main(void)
{
int pid, fd;
pid = forkpty(fd, 0, 0, 0);
if (!pid)
sleep(2);
else {
sleep(1);
printf(pid=%i fd=%i pgrp=%i\n, pid, fd, tcgetpgrp(fd));
}
}
Thanks, Andy. I had no idea how to do this.
D'oh, I'd actually written a very similar test before, except there
I'd looked at the slave side of the pty only:
http://www.cygwin.com/ml/cygwin-developers/2009-10/msg00101.html
So here's a test trying tcgetpgrp on both sides:
#include stdlib.h
#include stdio.h
#include unistd.h
#include pty.h
int main(void) {
int pid, master_fd, slave_fd;
openpty(master_fd, slave_fd, 0, 0, 0);
pid = fork();
if (!pid) {
close(master_fd);
login_tty(slave_fd);
sleep(2);
}
else {
sleep(1);
printf(pid=%i tcgetpgrp(master_fd)=%i tcgetpgrp(slave_fd)=%i\n,
pid, tcgetpgrp(master_fd), tcgetpgrp(slave_fd));
}
}
Cygwin 1.5:
pid=1072 tcgetpgrp(master_fd)=1072 tcgetpgrp(slave_fd)=1072
Cygwin 1.7:
pid=2440 tcgetpgrp(master_fd)=0 tcgetpgrp(slave_fd)=-1
Linux:
pid=23238 tcgetpgrp(master_fd)=23238 tcgetpgrp(slave_fd)=-1
I think the luit/tcsh problem that triggered the change from 1.5 to
1.7 only concerned the slave side.
On Linux, where it requires -lutil to link, this gives:
pid=13308 fd=3 tcgetpgrp(fd)=13308
I can confirm this on my Linux system. I mention this because apparently
tcgetpgrp isn't the same on all Linux systems. See below.
On Cygwin:
pid=268 fd=3 tcgetpgrp(fd)=0
Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because she
saw Linux doing that. But when I run Corinna's test on my Linux system, I
get -1 where she got 0. So not all Linuxes agree on what tcgetpgrp should
do.
Hmm, Corinna's test calls tcgetpgrp(master) in the parent only before
the child is forked and after it exited, so it's correct to report
that there's no foreground process.
I wonder which Linux it was that returned 0 in case of failure. I've
tried it on a recent Opensuse, an old Redhat with a 2.6.9 kernel, and
also a Debian with a 2.4 kernel, and got -1 on all of those.
Andy
--
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
Is python-xlib no longer available under Cygwin?
Hello, I am trying to install key-mon (http://freshmeat.net/projects/key-mon) under Cygwin; I've also tried installing Cygwin-X thinking python-xlib would be included, I but I get the same error: $ key-mon /usr/lib/python2.6/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could n ot open display warnings.warn(str(e), _gtk.Warning) Error: Missing xlib, run sudo apt-get install python-xlib Is python-xlib no longer supported? The last mention is [Cygwin-ports-announce] Uploads: 2007-Jun-03. -- 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: Where to get source for setup.exe?
On Tue, Oct 19, 2010 at 11:20 PM, Pan ruochen panruoc...@gmail.com wrote: Hi All, Where can I get the source package for the latest setup.exe. I used to implement a package filter on version 2.573.2.3. But now the old version of setup gets errors during installation. And I still want to apply filtering on setup. Filtering is now a part of the official setup.exe -- 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: Win7 64bit, why so slow?
Gerrit P. Haase schrieb am 19.10.2010 um 22:50 (+0200): Also, you might also be running into this problem: http://cygwin.com/ml/cygwin/2010-05/msg00190.html No bash completion here: $ time bash -i -c echo real0m0.312s user0m0.015s sys 0m0.076s And this wouldn't cause sh, m4 or perl scripts to run that slow like here, like all the autotools are incredible slow for me. I'm clueless as to whether it is related or not, but I've been enjoying a similarly bad slowdown on Win32 for about the last four weeks. I wouldn't say that it renders Cygwin totally useless, but it certainly does so for certain tasks which spawn a lot of processes, which is where i think the problem lies. Slowdown after update on Win32 (XP Home) http://cygwin.com/ml/cygwin/2010-09/msg00893.html But it might be a different one than what you are dealing with. Turning on -x on the shell clearly shows that the slowdown is due to process creation. Completion is out of the way, as I uninstalled it. Security software is something I don't have. bash is noticeable slower with completion activated, this I can confirm: $ time bash -i -c echo real0m1.731s user0m0.325s sys 0m0.699s $ time bash -i -c echo real0m8.025s user0m1.404s sys 0m0.794s $ time bash -i -c echo real0m7.910s user0m1.467s sys 0m0.779s $ time bash -i -c echo real0m6.560s user0m1.169s sys 0m0.734s -- Michael Ludwig -- 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: Sending signals to a subprocess
On 20 October 2010 13:20, Andy Koppe wrote:
Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because she
saw Linux doing that. But when I run Corinna's test on my Linux system, I
get -1 where she got 0. So not all Linuxes agree on what tcgetpgrp should
do.
Hmm, Corinna's test calls tcgetpgrp(master) in the parent only before
the child is forked and after it exited, so it's correct to report
that there's no foreground process.
I wonder which Linux it was that returned 0 in case of failure. I've
tried it on a recent Opensuse, an old Redhat with a 2.6.9 kernel, and
also a Debian with a 2.4 kernel, and got -1 on all of those.
Actually I'd only tried my test on all three systems, whereas I'd
tried Corinna's only on the old Redhat, where it did print -1 for
failure. On the 2.4 system it can't open /dev/ptmx, whereas on the
Opensuse with 2.6.34 I do get the results Corinna reported, including
0 on the master side of the pty when enquiring from the parent.
(Process 0 is the startup process, so I guess that makes some sense.)
To bring my ramblings to some sort of conclusion, here's a slightly
amended version of Corinna's test that checks the master side from the
parent process before, *during* and after the child process:
#define _XOPEN_SOURCE
#include stdio.h
#include stdlib.h
#include string.h
#include errno.h
#include sys/fcntl.h
#include sys/wait.h
#include unistd.h
#include termios.h
#include sys/ioctl.h
int main ()
{
int master, slave, status;
char pts[256];
printf (parent pid: %d\n, getpid ());
if ((master = open (/dev/ptmx, O_RDWR | O_NOCTTY)) = 0)
{
int ret;
grantpt (master);
unlockpt (master);
printf (parent tcgetpgrp master before child: %d\n, tcgetpgrp (master));
strcpy (pts, ptsname (master));
switch (fork ())
{
case -1:
break;
case 0: // child
ret = setsid ();
printf (child pid: %d (setsid: %d)\n, getpid (), ret);
printf (child tcgetpgrp master before open: %d\n,
tcgetpgrp(master));
if ((slave = open (pts, O_RDWR)) = 0)
{
printf (child tcgetpgrp master after open: %d\n,
tcgetpgrp (master));
printf (child tcgetpgrp slave: %d\n, tcgetpgrp (slave));
close (slave);
}
sleep(2);
break;
default:// parent
sleep(1);
printf (parent tcgetpgrp master during child: %d\n,
tcgetpgrp (master));
wait (status);
printf (parent tcgetpgrp master after child: %d\n,
tcgetpgrp (master));
break;
}
close (master);
return 0;
}
return 1;
}
On Cygwin 1.7:
parent pid: 5000
parent tcgetpgrp master before child: 0
child pid: 1572 (setsid: 1572)
child tcgetpgrp master before open: 0
child tcgetpgrp master after open: 1572
child tcgetpgrp slave: 1572
parent tcgetpgrp master during child: 0
parent tcgetpgrp master after child: 0
On Opensuse with 2.6.34 kernel:
parent pid: 13507
parent tcgetpgrp master before child: 0
child pid: 13508 (setsid: 13508)
child tcgetpgrp master before open: 0
child tcgetpgrp master after open: 13508
child tcgetpgrp slave: 13508
parent tcgetpgrp master during child: 13508
parent tcgetpgrp master after child: 0
Andy
--
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: Sending signals to a subprocess
On Wed, Oct 20, 2010 at 08:25:37PM +0100, Andy Koppe wrote: On 20 October 2010 13:20, Andy Koppe wrote: Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because she saw Linux doing that. ??But when I run Corinna's test on my Linux system, I get -1 where she got 0. ??So not all Linuxes agree on what tcgetpgrp should do. Hmm, Corinna's test calls tcgetpgrp(master) in the parent only before the child is forked and after it exited, so it's correct to report that there's no foreground process. I wonder which Linux it was that returned 0 in case of failure. I've tried it on a recent Opensuse, an old Redhat with a 2.6.9 kernel, and also a Debian with a 2.4 kernel, and got -1 on all of those. Actually I'd only tried my test on all three systems, whereas I'd tried Corinna's only on the old Redhat, where it did print -1 for failure. On the 2.4 system it can't open /dev/ptmx, whereas on the Opensuse with 2.6.34 I do get the results Corinna reported, including 0 on the master side of the pty when enquiring from the parent. (Process 0 is the startup process, so I guess that makes some sense.) To bring my ramblings to some sort of conclusion, here's a slightly amended version of Corinna's test that checks the master side from the parent process before, *during* and after the child process: FYI, I'm sticking with the test case that I first posted several days ago and which has been cruelly ignored ever since. I've been slowly modifying it for the last several days. I think I'm seeing some pattern to the way Linux handles this and I should be able to make Cygwin work the same way. Just in case it isn't clear, this all has nothing, AFAICT, to do with the fact that Cygwin doesn't implement TIO[CS]PGRP but I have implemented those two ioctl's nonetheless. cgf -- 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: Win7 64bit, why so slow?
On Tue, Oct 19, 2010 at 5:03 PM, Gerrit P. Haase gerrit.ha...@gmail.com wrote: On 19 October 2010 22:56, Gerrit P. Haase gerrit.ha...@gmail.com wrote: Norton Security is running, this may well be a problem, I'll try to disable this for now. Yes, much better now, seems to run very much faster now without Norton running... I guess I need to trash it. You just need to exclude the cygwin tree from its search vector -- 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: Sending signals to a subprocess
On 10/20/2010 4:32 PM, Christopher Faylor wrote: On Wed, Oct 20, 2010 at 08:25:37PM +0100, Andy Koppe wrote: On 20 October 2010 13:20, Andy Koppe wrote: Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because she saw Linux doing that. ??But when I run Corinna's test on my Linux system, I get -1 where she got 0. ??So not all Linuxes agree on what tcgetpgrp should do. Hmm, Corinna's test calls tcgetpgrp(master) in the parent only before the child is forked and after it exited, so it's correct to report that there's no foreground process. I wonder which Linux it was that returned 0 in case of failure. I've tried it on a recent Opensuse, an old Redhat with a 2.6.9 kernel, and also a Debian with a 2.4 kernel, and got -1 on all of those. Actually I'd only tried my test on all three systems, whereas I'd tried Corinna's only on the old Redhat, where it did print -1 for failure. On the 2.4 system it can't open /dev/ptmx, whereas on the Opensuse with 2.6.34 I do get the results Corinna reported, including 0 on the master side of the pty when enquiring from the parent. (Process 0 is the startup process, so I guess that makes some sense.) To bring my ramblings to some sort of conclusion, here's a slightly amended version of Corinna's test that checks the master side from the parent process before, *during* and after the child process: FYI, I'm sticking with the test case that I first posted several days ago and which has been cruelly ignored ever since. I've been slowly modifying it for the last several days. I didn't ignore it. I just didn't know how to modify it to deal with subprocesses, which was the situation I was trying to understand. I think I'm seeing some pattern to the way Linux handles this and I should be able to make Cygwin work the same way. That would be great. Thanks. Just in case it isn't clear, this all has nothing, AFAICT, to do with the fact that Cygwin doesn't implement TIO[CS]PGRP but I have implemented those two ioctl's nonetheless. It's clear, and I agree. 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: cygcheck bug: symlinks with unix paths are wrongly resolved
On 2010-10-19 19:17, Arseny Slobodyuk wrote: [snip...] a...@dstar ~ $ ln -s `which cmd.exe` cmd.exe a...@dstar ~ $ cygcheck ./cmd.exe - D:\OTHERBIN\cygwin\cygdrive\d\WINDOWS\system32\cmd.exe cygcheck: could not find './cmd.exe' cygcheck is not a cygwin application, it's a native windows application, so it does not know how to resolve unix paths. -- 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: cygcheck bug: symlinks with unix paths are wrongly resolved
On Wed, Oct 20, 2010 at 07:46:05PM -0400, Rolf Campbell wrote: On 2010-10-19 19:17, Arseny Slobodyuk wrote: [snip...] a...@dstar ~ $ ln -s `which cmd.exe` cmd.exe a...@dstar ~ $ cygcheck ./cmd.exe - D:\OTHERBIN\cygwin\cygdrive\d\WINDOWS\system32\cmd.exe cygcheck: could not find './cmd.exe' cygcheck is not a cygwin application, it's a native windows application, so it does not know how to resolve unix paths. Sure it does: VVV c:\cygcheck /usr/bin/ls.exe C:\cygwin\bin\ls.exe c:\cygwin\bin\cygwin1.dll C:\WINXP\system32\ADVAPI32.DLL C:\WINXP\system32\KERNEL32.dll C:\WINXP\system32\ntdll.dll C:\WINXP\system32\RPCRT4.dll C:\WINXP\system32\Secur32.dll c:\cygwin\bin\cygintl-8.dll c:\cygwin\bin\cygiconv-2.dll c:\cygwin\bin\cyggcc_s-1.dll And also: bash-3.2$ cd /cygdrive/c/winxp/system32 bash-3.2$ cygcheck ./cmd.exe C:\winxp\system32\cmd.exe C:\winxp\system32\KERNEL32.dll C:\winxp\system32\ntdll.dll C:\winxp\system32\msvcrt.dll C:\winxp\system32\USER32.dll C:\winxp\system32\GDI32.dll cgf -- 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: cygcheck bug: symlinks with unix paths are wrongly resolved
Greetings, Christopher Faylor! [snip...] a...@dstar ~ $ ln -s `which cmd.exe` cmd.exe a...@dstar ~ $ cygcheck ./cmd.exe - D:\OTHERBIN\cygwin\cygdrive\d\WINDOWS\system32\cmd.exe cygcheck: could not find './cmd.exe' cygcheck is not a cygwin application, it's a native windows application, so it does not know how to resolve unix paths. Sure it does: Not to mention, the Windows itself don't see much of a difference between / and \ in path. (where it see, it is a bug). -- WBR, Andrey Repin (anrdae...@freemail.ru) 21.10.2010, 6:45 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: cygcheck bug: symlinks with unix paths are wrongly resolved
On Thu, Oct 21, 2010 at 06:46:16AM +0400, Andrey Repin wrote: Greetings, Christopher Faylor! [snip...] a...@dstar ~ $ ln -s `which cmd.exe` cmd.exe a...@dstar ~ $ cygcheck ./cmd.exe - D:\OTHERBIN\cygwin\cygdrive\d\WINDOWS\system32\cmd.exe cygcheck: could not find './cmd.exe' cygcheck is not a cygwin application, it's a native windows application, so it does not know how to resolve unix paths. Sure it does: Not to mention, the Windows itself don't see much of a difference between / and \ in path. (where it see, it is a bug). I should clarify. cygcheck does understand UNIX paths. It does not understand symlinks just like the OP said. Sorry for not making that clear. cgf -- 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: Bash problems, strace, performance, etc.
seems to work here ! even on cpan.1 generated from pod2man... do you have bash-completion, if yes, get rid of it and try again. PS : where do you find the Club-G package ? Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net -- 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
