Re: Personal use not permitted: (was Re: Pop up GUI remotely via SSH)

[trimat]

Very thanks for your thorough response.

We wanted to achieve that triggering commands from a Windows/Linux to a
Windows (7), so in a mono-directional way. We realize the difficulty to
realize it and so we decided to shake our architecture up.



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/Pop-up-GUI-remotely-via-SSH-tp122269p122747.html
Sent from the Cygwin list mailing list archive at Nabble.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: 2.3.0: possible Cygwin flock bug (Windows 10 x86_64)

[Corinna Vinschen]

On Nov 13 13:25, Mario Roy wrote:
> Hello Corinna,
> 
> I am writing to confirm that file locking, with MCE 1.608, utilizing
> the development snapshot 2015-11-12 x86_64 is passing 100%. I ran
> through other test cases including mixing threads and child processes.

Thanks for testing and confirming.  I uploaded the new Cygwin 2.3.1
already on Saturday.

> [...]
> MCE 1.700 in Github runs well with channel locking across the board.
> However, being able to obtain a shared lock (possible with file
> locking) at the application level is nice. Seeing the above example
> work makes me confident in bringing back file locking and know that it
> will work across platforms including Cygwin.

Sounds good.


Thanks,
Corinna

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


pgpqw6wLeOiYn.pgp
Description: PGP signature

Re: CYGWIN 2.3.0 [32/64]: strtold() seems to be broken

[Corinna Vinschen]

Hi Tino,

On Nov 13 12:58, Tino Lange wrote:
> Hi Cygwin Developers,
> 
> strtold() seems to be broken, at least when there is additional
> non-numeric data after the initial numeric part.
> 
> Code:
> 
> > #include 
> > #include 
> > 
> > int main()
> > {
> >   char* endptr;
> >   const char * v = "1234abc";
> >   const long double value = strtold(v, &endptr);
> >   std::cout << v << " -> " << value << "\n";
> > }
> 
> Linux (expected result):
> > 1234abc -> 1234
> 
> CYGWIN (unexpected/wrong result):
> > 1234abc -> -e+999
> 
> Note that using strtod() instead of strtold() on CYGWIN gives the
> expected result. strtod() and strtold() implementations seem to differ
> here.
> 
> BTW: There seem to be more strange things going on with strtold() on
> CYGWIN32/64, see also:
> https://stackoverflow.com/questions/29040427/unexpected-endptr-with-strtod-strtold
> (tested today with recent CYGWIN, the reported inconsistency can still
> be reproduced).
> 
> "cygcheck.out" attached (from a CYGWIN64 box, but this can also be
> reproduced on a CYGWIN32 box).

Strtold is implemented in newlib, our underlying libc, so this doesn't
only affect Cygwin but all newlib targets.  Would you mind to report
this to the newlib AT sourceware DOT org mailing list so we can discuss
this there?


Thanks,
Corinna

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


pgpOiwdgXXkNH.pgp
Description: PGP signature

Command echo

[Gluszczak, Glenn]

When I shell to cmd.exe, the commands I execute are echoed (not sure if stdout 
or stderr).
This doesn't happen under native cmd.exe.  Is there a variable that controls 
this?  
I only have CYGWIN=nodosfilewarning

Notice the commands "dir" and "whoami" are emitted to the output.  


$ bash --version
GNU bash, version 4.3.42(4)-release (i686-pc-cygwin)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ cmd
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\cygwin\home\mytest>whoami
whoami
mytest


C:\cygwin\home\mytest>dir
dir
Volume in drive C has no label.
Volume Serial Number is 0EA8-F3D1

Directory of C:\cygwin\home\mytest

11/11/2015  09:31 AM      .
11/11/2015  09:31 AM      ..
11/05/2015  05:55 AM 6,054 .bashrc
11/11/2015  09:45 AM 2,401 .bash_history
11/05/2015  05:55 AM 1,494 .bash_profile






--
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: gcc segfault on cygwin 2.3.1-1 with aircrack-ng svn r2719

[Corinna Vinschen]

On Nov 14 12:59, tdotre...@aircrack-ng.org wrote:
> Hi,
> 
> I just updated to cygwin 2.3.1-1 after
> https://cygwin.com/ml/cygwin/2015-11/msg00186.html1 to see if the update
> solves the issue but it still segfaults. I only tested gcc 5.2.0-1 and I'm
> pretty sure it's gonna happen on every other gcc version available since the
> output is exactly the same as on 2.3.0:

I tried to build aircrack-ng-1.2-rc2 on 2.3.1 and didn't encounter this
problem.  If that's not the right thing to do to test the issue, please
provide the full set of commands to reproduce the issue.


Thanks,
Corinna

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


pgppauOJ1jlBb.pgp
Description: PGP signature

RE: Command echo

[Buchbinder, Barry (NIH/NIAID) [E]]

Gluszczak, Glenn sent the following at Monday, November 16, 2015 11:16 AM
>
>When I shell to cmd.exe, the commands I execute are echoed (not sure if
>stdout or stderr). This doesn't happen under native cmd.exe. Is there a
>variable that controls this? I only have CYGWIN=nodosfilewarning
>
>Notice the commands "dir" and "whoami" are emitted to the output.

cmd.exe is in control of its own echoing.  Try starting as cmd /q
cmd /?
...
/Q  Turns echo off
...

As to why cmd behaves differently when started under bash (even in a
non-mintty window) than when started directly or under cmd 

Hope that helps.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

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

Newline missing in csh

[Gluszczak, Glenn]

cat "/proc/registry/HKEY_CURRENT_USER/Control Panel/International/sLanguage" 
works fine in bash
but if I switch to csh I fail to get a newline when reading the registry.

$ cat -v "/proc/registry/HKEY_CURRENT_USER/Control 
Panel/International/sLanguage"
ENU^@
$ csh
$ cat -v "/proc/registry/HKEY_CURRENT_USER/Control 
Panel/International/sLanguage"
ENU^@$




--
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: Command echo

[Andrew DeFaria]

On 11/16/2015 08:40 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote:

Gluszczak, Glenn sent the following at Monday, November 16, 2015 11:16 AM


When I shell to cmd.exe, the commands I execute are echoed (not sure if
stdout or stderr). This doesn't happen under native cmd.exe. Is there a
variable that controls this? I only have CYGWIN=nodosfilewarning

Notice the commands "dir" and "whoami" are emitted to the output.


cmd.exe is in control of its own echoing.  Try starting as cmd /q
cmd /?
...
/Q  Turns echo off
...

As to why cmd behaves differently when started under bash (even in a
non-mintty window) than when started directly or under cmd 

Hope that helps.

- Barry
   Disclaimer: Statements made herein are not made on behalf of NIAID.


Mintty (and ssh, etc.) use pty's. cmd does not understand pty's. So if 
you run say Cygwin's bash from a cmd window and then start cmd you will 
not get the echoing. If, however, you start cmd from a bash shell that 
is in a mintty window then you're using pty's and you'll get echoing. 
Likewise if you run bash in a cmd window, then say ssh to another 
machine, you're now using pty's and you'll see the behavior again.

--
Andrew DeFaria
http://defaria.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: CTRL-C not working in sh login mode?

[Benjamin Cao]

-Original Message-
From: Benjamin Cao 
Sent: Friday, November 13, 2015 3:46 PM
To: 'cygwin@cygwin.com'
Subject: CTRL-C not working in sh login mode?

Hi,

We invoke a shell using a *.bat file doing sh --login.

We have discovered that when wanting to kill a long running process with 
CTRL-C, it does not work.

Is this expected behavior?

I've found that to be the same even if I am doing bash --login -i in my *.bat 
file.

Any guidance would be greatly appreciated.


Hi,

Just wanted to provide some additional information to make things a bit clearer.

Running either "sh -login" or "bash --login -I" from a *.bat file will cause 
some commands to not be broken with CTRL-C.

For example, this test loop cannot be broken with CTRL-C when I start Cygwin up 
from the *.bat file.

echo foo | perl -e 'while(1) {sleep 60;}'

Or if I do "cat  | more", CTRL-C does not work in that case.

Again, is that expected behavior?

Thanks,
Ben Cao

--
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: Newline missing in csh

[John Hein]

Gluszczak, Glenn wrote at 17:43 + on Nov 16, 2015:
 > cat "/proc/registry/HKEY_CURRENT_USER/Control Panel/International/sLanguage" 
 > works fine in bash
 > but if I switch to csh I fail to get a newline when reading the registry.
 >
 > $ cat -v "/proc/registry/HKEY_CURRENT_USER/Control 
 > Panel/International/sLanguage"
 > ENU^@
 > $ csh
 > $ cat -v "/proc/registry/HKEY_CURRENT_USER/Control 
 > Panel/International/sLanguage"
 > ENU^@$

In bash, 'set PS1=x' and try again.  Looks like it's just a side
effect of your prompt settings.

It's not that bash is working "fine", but that your bash prompt is
adding a newline that's not part of the data in the file you're
reading.  And your expectation that the added newline makes it the
correct behavior is flawed.

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

gnuplot 5.x.x.x not starting correctly in 64-bit CYGWIN console

[John J Ottusch]

I think this problem is related to the fact that I have both 32-bit and
64-bit versions of CYGWIN installed on my Windows 7 PC. They are on the 
same disk but in different directories (/cygdrive/c/win32app/cygwin vs. 
/cygdrive/c/win64app/cygwin).

So far I have observed the problem only when I try to run the version of 
gnuplot that comes with the most recent 64-bit CYGWIN installation. I 
believe gnuplot v4.x.x.x had been working in 64-bit CYGWIN before I 
updated.

I always run gnuplot from an X11 or rxvt console window within the 
CYGWIN environment. I'm using v4.4.4 with my 32 bit CYGWIN installation 
without any problems. 

I just updated my 64 bit CYGWIN installation in order to try out gnuplot 
v5.x.x. I didn't load absolutely everything, but I did accept all 
automatic dependencies. Installation went smoothly and all seems to work 
fine except for gnuplot.

Observations:

1) When I type gnuplot into a 64-bit console window it returns 
immediately to my prompt with no visible message instead of entering 
interactive mode. 

In this case my PATH is
/usr/local/bin:/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/win32ap
p/cygwin/bin

2) However, doing the above with /cygdrive/c/win32app/cygwin/bin removed 
from my PATH (or replaced by /cygdrive/c/win64app/cygwin/bin) produces 
this error message:

C:/win64app/cygwin/bin/gnuplot.exe: error while loading shared 
libraries: ?: cannot open shared object file: No such file or directory

So something in /cygdrive/c/win32app/cygwin/bin is making a difference. 
Hard for me to tell from the error message which shared library it is 
looking for.

3) I wouldn't necessarily expect it to work correctly if I try to start 
gnuplot.exe directly from the filename in Windows Explorer, but at least 
I get an error message -- "The application was unable to start correctly 
(0xc07b). 


Any suggestions on how to fix or debug the problem would be appreciated. 

John Ottusch

PS. I tried attaching the outputs from 'cygcheck -s -v -r' for cases 1 
and 2 but that message apparently got bounced somewhere along the line.




--
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: gnuplot 5.x.x.x not starting correctly in 64-bit CYGWIN console

[Ken Brown]

On 11/16/2015 4:26 PM, John J Ottusch wrote:

I think this problem is related to the fact that I have both 32-bit and
64-bit versions of CYGWIN installed on my Windows 7 PC. They are on the
same disk but in different directories (/cygdrive/c/win32app/cygwin vs.
/cygdrive/c/win64app/cygwin).

So far I have observed the problem only when I try to run the version of
gnuplot that comes with the most recent 64-bit CYGWIN installation. I
believe gnuplot v4.x.x.x had been working in 64-bit CYGWIN before I
updated.

I always run gnuplot from an X11 or rxvt console window within the
CYGWIN environment. I'm using v4.4.4 with my 32 bit CYGWIN installation
without any problems.

I just updated my 64 bit CYGWIN installation in order to try out gnuplot
v5.x.x. I didn't load absolutely everything, but I did accept all
automatic dependencies. Installation went smoothly and all seems to work
fine except for gnuplot.

Observations:

1) When I type gnuplot into a 64-bit console window it returns
immediately to my prompt with no visible message instead of entering
interactive mode.

In this case my PATH is
/usr/local/bin:/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/win32ap
p/cygwin/bin

2) However, doing the above with /cygdrive/c/win32app/cygwin/bin removed
from my PATH (or replaced by /cygdrive/c/win64app/cygwin/bin) produces
this error message:

C:/win64app/cygwin/bin/gnuplot.exe: error while loading shared
libraries: ?: cannot open shared object file: No such file or directory

So something in /cygdrive/c/win32app/cygwin/bin is making a difference.
Hard for me to tell from the error message which shared library it is
looking for.


The command 'cygcheck /usr/bin/gnuplot.exe' should give you that 
information.


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: gnuplot 5.x.x.x not starting correctly in 64-bit CYGWIN console

[John J Ottusch]

>>  The command 'cygcheck /usr/bin/gnuplot.exe' should give you that 
information.

>> Ken

Doing so finds several required DLL's but also reports

  cygcheck: track_down: could not find cyglua-5.1.dll

which is interesting because running the command

  lua

enters an interactive mode (unlike gnuplot), which suggests that 'lua' 
might be working.

If cyglua-5.1.dll is part of the normal 64-bit CYGWIN download then

1) I don't understand why it wasn't downloaded and installed 
automatically when I updated, and

2) I'm not sure what package(s) I would have to manually (re)install in 
order to get the 64-bit version, and

3) it may or may not fix the gnuplot startup problem.

I might add that running 'cygcheck gnuplot' from my 32-bit CYGWIN 
installation finds cyglua-5.1.dll in C:\win32app\cygwin\bin\cyglua-
5.1.dll. Of course this version does not work with 64-bit gnuplot.

jjo

(Sorry for the lack of previous context, but I did not receive a copy of 
Ken's message in my e-mail box to reply to.)


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

Can MKS Toolkit and Cygwin safely co-exist on Windows servers?

[Kenneth Wolcott]

Hi;

  I now work in a Windows-centric build and release environment.

  The MKS Toolkit currently exists on most (if not all) of the Windows servers.

  If I were to install Cygwin, would it conflict with MKS Toolkit?

  Secondly, I'm really confused about 32bit versus 64bit servers;
should I just use 32bit Cygwin to be sure?

  I'd like to eventually replace MKS Toolkit with Cygwin if everything
works out.

  I have the feeling that I'm wading into the deep part of the pool
and I don't know how to swim :-)

  Thanks in advance for advice and pointers.

Thanks,
Ken Wolcott

--
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: Can MKS Toolkit and Cygwin safely co-exist on Windows servers?

[Warren Young]

On Nov 16, 2015, at 5:54 PM, Kenneth Wolcott  wrote:
> 
>  If I were to install Cygwin, would it conflict with MKS Toolkit?

It shouldn’t.

However, you cannot expect any cross-process mechanisms to work correctly 
across that boundary like pipes, shared memory, and other forms of IPC that 
don’t map 1:1 to native Windows mechanisms.

(So, TCP/IP will be compatible across the boundary, since both MKS and Cygwin 
implement BSD sockets in terms of Winsock.)

>  Secondly, I'm really confused about 32bit versus 64bit servers;
> should I just use 32bit Cygwin to be sure?

Almost certainly not: http://stackoverflow.com/a/18333049


--
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: gnuplot 5.x.x.x not starting correctly in 64-bit CYGWIN console

[Ken Brown]

On 11/16/2015 7:01 PM, John J Ottusch wrote:

  The command 'cygcheck /usr/bin/gnuplot.exe' should give you that

information.


Ken


Doing so finds several required DLL's but also reports

   cygcheck: track_down: could not find cyglua-5.1.dll

which is interesting because running the command

   lua

enters an interactive mode (unlike gnuplot), which suggests that 'lua'
might be working.


You probably have lua5.2 installed, which provides cyglua-5.2.dll rather than 
cyglua-5.1.dll.



If cyglua-5.1.dll is part of the normal 64-bit CYGWIN download then


I'm not sure what you mean by the "normal" download, but cyglua-5.1.dll is part 
of the lua5.1 package, and the latter is required by gnuplot.



1) I don't understand why it wasn't downloaded and installed
automatically when I updated, and


It should have been.


2) I'm not sure what package(s) I would have to manually (re)install in
order to get the 64-bit version, and


As I mentioned above, you will need to install (or reinstall) lua5.1. You can 
discover this kind of thing by going to the Cygwin website and clicking on 
"Search Packages" in the left column.



(Sorry for the lack of previous context, but I did not receive a copy of
Ken's message in my e-mail box to reply to.)


You should subscribe to the cygwin mailing list (or use something like gmane). 
The custom on this list is not to CC individuals, though I've made an exception 
this time to make sure you get the message.


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: Newline missing in csh

[Andrey Repin]

Greetings, Gluszczak, Glenn!

> cat "/proc/registry/HKEY_CURRENT_USER/Control
> Panel/International/sLanguage" works fine in bash
> but if I switch to csh I fail to get a newline when reading the registry.

> $ cat -v "/proc/registry/HKEY_CURRENT_USER/Control 
> Panel/International/sLanguage"
> ENU^@
> $ csh
> $ cat -v "/proc/registry/HKEY_CURRENT_USER/Control 
> Panel/International/sLanguage"
> ENU^@$

cat -v "/proc/registry/HKEY_CURRENT_USER/Control Panel/International/sLanguage" 
| od -t x1


-- 
With best regards,
Andrey Repin
Tuesday, November 17, 2015 04:27:55

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: Can MKS Toolkit and Cygwin safely co-exist on Windows servers?

[Peter A. Castro]

On Mon, 16 Nov 2015, Kenneth Wolcott wrote:


Date: Mon, 16 Nov 2015 16:54:00 -0800
From: Kenneth Wolcott
Subject: Can MKS Toolkit and Cygwin safely co-exist on Windows servers?

Hi;


Greetings, Kenneth,


 I now work in a Windows-centric build and release environment.


I feel you pain :)


 The MKS Toolkit currently exists on most (if not all) of the Windows servers.

 If I were to install Cygwin, would it conflict with MKS Toolkit?


Yes and no.  The toolset overlaps, obviously.  Some behaviours will be 
different as some features in MKS may or may not be the same in Cygwin,
vis-a-versa.  But if you are thinking of having both paths in %PATH%, 
then, no, just don't do that.  Use one or the other.



 Secondly, I'm really confused about 32bit versus 64bit servers;
should I just use 32bit Cygwin to be sure?


MKS, unless I'm mistaken, is (still?) 32-bit, but that's not really saying 
much.  I guess the answer would gate on what specifically you are 
concerned about.  The 64-bit release of Cygwin is stable and mostly as 
complete as the 32-bit offering.


The two toolsets will only externally interface, like any other console 
program on Windows (eg: pipes, sockets, process spawning, file handles, 
etc) but other aspects (IPC, memory sharing, threading, etc) won't cross 
between them.


Other thinks might get in the way.  MKS still supports/prefers using DOS 
file syntax while Cygwin prefers the Unix/POSIX syntax, which can present 
a problem for generating file paths and feeding them to some non-Cygwin 
programs (re: "/cygdrive").


Cygwin also has a concept of an installation root where important things 
live (like config files in "/etc").  MKS has less of this kind of locality 
but does have some of it none the less.


32-bit vs 64-bit?  Not really much difference.  You might as well use the 
64-bit release as everything will eventually be 64-bit.



 I'd like to eventually replace MKS Toolkit with Cygwin if everything
works out.


Oh!  I've been there and tried to do that but was shutdown for corporate 
policy reasons.  Remember that business wants someone to shoot at when 
things break.  That license you have for MKS means your company can demand 
support from someone.  Cygwin is "free" and support is really just this 
email list and "WJM". :)


That being said, I was able to swap out MKS for Cywgin (at least on my 
workstation) and it largely worked very well.  Some things were slower, 
but the toolset offering is much richer and I was able to use commands not 
available in MKS.



 I have the feeling that I'm wading into the deep part of the pool
and I don't know how to swim :-)


Deep and very cold too!  I wish you well on your adventure!


 Thanks in advance for advice and pointers.


Don't try and use MKS and Cygwin together.  Use one set or the other.  If 
you have any other tools that use explict paths, change them to not do 
that.  There will be differences, so resign yourself to this fact and work 
to make your other tools environment agnostic.


CR/LF may become your enemy as some tools will still make some assumptions 
about line termination.  There's no right/wrong here.


In my particular case, we swapped out "make" and most of the other 
command-line tools just fine, but ran into file path differences for 
things like a 3rd-party compiler that doesn't like "/" in unquoted path 
names.  Also, try and not to use absolute paths.


Good luck!


Thanks,
Ken Wolcott


--
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
"Cats are just autistic Dogs" -- Dr. Tony Attwood

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