Re: Cygwin uninstall: Problem with /dev/nul

[Peter Rosin]

Den 2010-10-01 02:49 skrev Al:
>>
>> cd /dev
>> rm -f nul

Someone, somewhere, has done

echo crap > /dev/nul

instead of the intended

echo crap > /dev/null

If the /dev/nul file is still around it should be possible to
examine it and possible identify the culprit.

It might be some script in Cygwin, but I'm going to go out on a limb
and suggest that it is more probable that it is an end-user typo.

Cheers,
Peter

--
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: R: Cygwin 1.7.7 fork/exec performance MUCH slower than 1.5.25

[SZABÓ Gergely]

Ciao Marco,

I do not think a real /home would help, as I have several colleagues who
have a real /home, but still have similar slow performance with cygwin
1.7.x. 

What kind of ACL issue could this be? And why is it no problem for
Cygwin 1.5.25? Anything to do with the new cyglsa.dll?

The funny thing is, The sum of the sys and user times for the "fork"
script is around 1 minute. What happens in the remaining 3 minutes, to
make up that terrible time over 4 min?

If I am watching the Windows Task Manager during the execution of the
"fork" script, I see that the process "System" eats more than 50% of the
CPU all the time. 

Best regards
Gergely

P.S: this is all Win32 (not x64) as you can see from the cygcheck
files...


--
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: diff issue

[Brian Wilson]

>>> Let's say I have two versions of the same batch file:
>>> The old version from CVS:
>>> 
>>> > rem $Id: backup.bat,v 1.1 2007/07/17 01:53:30 Daemon Exp $
>>> > rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list
>>> 
>>> The new version I've imported to Subversion:
>>> 
>>> > @echo off
>>> > rem $Id: backup.bat 10 2010-09-30 01:22:14Z anrdaemon $
>>> > rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list
>>> 
>>> When I'm comparing them with my usual macro
>>> diff -bdu -x "CVS" -x ".svn" -I "\$Id.*\$" -I "\$Revision.*\$" -I 
>>> "\$Date.*\$" -I "\$Author.*\$" --strip-trailing-cr -- '1/backup.bat' 
>>> 'backup.bat'
>>> 
>>> It telling me that $Id$ lines are differ.
>>> But when I remove the "@echo off" from second file, it telling me 
>>> that files are "identical" (the expected result).
>>> 
>>> Having hard times dechiphering man diff, so if anyone can enlighten 
>>> me in simple words on the matter, I'd appreciate help greatly.
> 
>> Be sure the end of line characters are correct on the "@echo" line.  You 
>> should be able to do this with a "cat -vTE" command.
> 
> They are "correct" for windows batch fine (CRLF) and consistent for both
> files.  However, changing line endings didn't changed the end result. I'm 
> leaning
> towards diff specifics in treatment of ignored lines in scope of actually
> changed lines.
> 
> :) If my English was the same as your Russian, accept my deepest apology.

Your English is fine.  I used Google translate to try and make my response 
easier for you.  I guess that didn't happen, so 
the fault is mine.

Try changing the "@echo" line to something else and see if you still get the 
same results.  Also try removing some of the -I 
cases and see if that makes a difference in the results.  This could lead you 
to the answer if one of the patterns is causing 
the problem.  Lastly do you need to use the "-x PATtern" exclusion options?  
You are already specifying the two files to diff 
so you shouldn't need these options.

I'm not sure what the "--" argument is used for (before the file names) though. 
 I would also try naming the directory in the 
"1/backup.bat" argument something other than "1".

--
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: git stopped working with 1.7.1

[survivant]

that's really a patch :)

but no choice.. 

I create a post on java.net  Hope to get more feedback, to get this problem
solve soon.

Unix users are making fun of us :)


Tomás Staig wrote:
> 
> survivant wrote:
>> Does anyone one have an answer for this problem ?  (I saw lot of threads
>> in
>> different forums.. but never an answer.)
>>
>> I'm trying to clone a repository from my computer to my computer.  I,m
>> using
>> cygwin 1.7.   I,m able to clone all my others projects without problems. 
>> This project is 900k.. and the others are better than that.
>>
>>  
>>
>> I have no idea what going on.  I deleted the project and repush it..
>> always
>> the same problems.
>>
>>  
>>
>> $ GIT_TRACE=1 git clone g...@localhost:SmallProject.git
>> trace: built-in: git 'clone' 'g...@localhost:SmallProject.git'
>>
>> Cloning into SmallProject...
>> trace: run_command: 'ssh' 'g...@localhost' 'git-upload-pack
>> '\''SmallProject.git'\'''
>> DEBUG:gitosis.serve.main:Got command "git-upload-pack 'SmallProject.git'"
>> DEBUG:gitosis.access.haveAccess:Access check for 'jerabi' as 'writable'
>> on
>> 'SmallProject.git'...
>> DEBUG:gitosis.access.haveAccess:Stripping .git suffix from
>> 'SmallProject.git', new value 'SmallProject'
>> DEBUG:gitosis.group.getMembership:found 'jerabi' in 'gitosis-admin'
>> DEBUG:gitosis.group.getMembership:found 'jerabi' in 'dev_jerabi'
>> DEBUG:gitosis.access.haveAccess:Access ok for 'jerabi' as 'writable' on
>> 'SmallProject'
>> DEBUG:gitosis.access.haveAccess:Using prefix 'repositories' for
>> 'SmallProject'
>> DEBUG:gitosis.serve.main:Serving git-upload-pack
>> 'repositories/SmallProject.git'
>> trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin'
>> '--keep=fetch-pack 6900 on jerabi-THINK'
>> trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin'
>> '--keep=fetch-pack 6900 on jerabi-THINK'
>> remote: Counting objects: 344, done.
>> trace: built-in: git 'index-pack' '--stdin' '-v' '--fix-thin'
>> '--keep=fetch-pack 6900 on jerabi-THINK'
>> remote: Compressing objects:  58% (134/230)
>> remote: Compressing objects: 100% (230/230), done.
>> fatal: The remote end hung up unexpectedly
>> fatal: early EOF
>> fatal: index-pack failed
>>
>> jer...@jerabi-think ~/workspaces/test
>> $
>>
>> $ git --version
>> git version 1.7.2.3
>>   
> Don't have a clue of why this happens (some people say it is because of 
> openssh, that if you change it for putty's implementation it works well) 
> but when that happens to me (while pulling, never tried with clone) I 
> just try a couple of times until it succeeds:
> 
> for (( i=0 ; i < 100 ; i++ )); do git pull; done
> 
> works all the time for me... try something similar but with "git clone 
> ..." of course.
> 
> And well, I'm working with a 4+GB repository, so I'm really thankful 
> that the clone worked right away.
> 
> I know it's not the best solution, but if it works... it's good enough 
> as a temporal workaround.
> Hope it works for you.
> 
> Cheers,
> Tomas.
> 
> --
> 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
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/git-stopped-working-with-1.7.1-tp26905956p29853811.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: Cygwin uninstall: Problem with /dev/nul

[Al]

>
> cd /dev
> rm -f nul
>

I havn't seen that, but simliar.  There remained setup.log and
setup.log.ful on my Desktop and I couldn't delete them.

>From another Cygwin installation I was able to remove them with your receipe.

rm -rf /cygdrive/c/Users/prefix/Desktop/setup.log
rm -rf /cygdrive/c/Users/prefix/Desktop/setup.log.full

Al

--
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: Slowdown after update on Win32 (XP Home)

[Larry Hall (Cygwin)]

On 9/30/2010 7:19 PM, Michael Ludwig wrote:

I'm seeing a painfully noticeable slowdown on my system. I must have
contracted this slowdown last week. My Cygwin is up to date as of now,
October 1st, 01:00 CET

Starting a MinTTY (or rxvt, for that matter) from the icon I've placed
in the start menu does not take the usual two or three seconds, but may
take as much as a whole minute. During this startup attempt phase, I can
see various bash processes with different PIDs bubbling to the top in
taskmgr. I've seen up to three of them at the same time when my MinTTY
was trying to start as the first Cygwin process, so there should have
been no other bash processes around.

This is Win32, XP Home SP3.

I hope this description is helpful in debugging this issue.


Could you provide the information requested by the problem reporting
guidelines: 

My WAG is you're suffering from changes in the new version of
bash_completion.  If you don't use this, uninstall it.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


--
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: Cygwin uninstall: Problem with /dev/nul

[Andrey Repin]

Greetings, Max Funk!

> If I delete the folder cygwin on my PC (Windows 7, 32 bit),
> as described in the FAQ "Cygwin uninstall", then there is 
> remaining a special file 

> C:\cygwin\dev\nul

> This file cannot be deleted afterwards from windows
> (at least, I didn't find any possibility.) 

http://www.farmanager.com/
Get the 2.0 for your platform and forget your file access nightmares.
It can create and delete any technically possible file names.


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 01.10.2010, <4:25>

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: diff issue

[Andrey Repin]

Greetings, Brian Wilson!

>> I have strange (to me) issue that I'm not entirely sure how to interpret.
>> 
>> Let's say I have two versions of the same batch file:
>> 
>> The old version from CVS:
>> 
>> > rem $Id: backup.bat,v 1.1 2007/07/17 01:53:30 Daemon Exp $
>> > rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list
>> 
>> The new version I've imported to Subversion:
>> 
>> > @echo off
>> > rem $Id: backup.bat 10 2010-09-30 01:22:14Z anrdaemon $
>> > rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list
>> 
>> When I'm comparing them with my usual macro
>> diff -bdu -x "CVS" -x ".svn" -I "\$Id.*\$" -I "\$Revision.*\$" -I 
>> "\$Date.*\$" -I "\$Author.*\$" --strip-trailing-cr -- '1/backup.bat' 
>> 'backup.bat'
>> 
>> It telling me that $Id$ lines are differ.
>> But when I remove the "@echo off" from second file, it telling me 
>> that files are "identical" (the expected result).
>> 
>> Having hard times dechiphering man diff, so if anyone can enlighten 
>> me in simple words on the matter, I'd appreciate help greatly.

> Be sure the end of line characters are correct on the "@echo" line.  You 
> should be able to do this with a "cat -vTE" command.

They are "correct" for windows batch fine (CRLF) and consistent for both
files.
However, changing line endings didn't changed the end result. I'm leaning
towards diff specifics in treatment of ignored lines in scope of actually
changed lines.

> (sorry for my terrible Russian)

:) If my English was the same as your Russian, accept my deepest apology.


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 01.10.2010, <4:17>

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: Slowdown after update on Win32 (XP Home)

[Michael Ludwig]

Michael Ludwig schrieb am 01.10.2010 um 01:19 (+0200):
> I'm seeing a painfully noticeable slowdown on my system. I must have
> contracted this slowdown last week. My Cygwin is up to date as of now,
> October 1st, 01:00 CET

For a bit more precision, here's an excerpt from $(cygcheck -s):

Cygwin DLL version info:
DLL version: 1.7.7
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 230
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Program options name: Program Options
Installations name: Installations
Cygdrive default prefix:
Build date:
Shared id: cygwin1S5

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

Slowdown after update on Win32 (XP Home)

[Michael Ludwig]

I'm seeing a painfully noticeable slowdown on my system. I must have
contracted this slowdown last week. My Cygwin is up to date as of now,
October 1st, 01:00 CET

Starting a MinTTY (or rxvt, for that matter) from the icon I've placed
in the start menu does not take the usual two or three seconds, but may
take as much as a whole minute. During this startup attempt phase, I can
see various bash processes with different PIDs bubbling to the top in
taskmgr. I've seen up to three of them at the same time when my MinTTY
was trying to start as the first Cygwin process, so there should have
been no other bash processes around.

This is Win32, XP Home SP3.

I hope this description is helpful in debugging this issue.
-- 
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: Cygwin uninstall: Problem with /dev/nul

[Rance Hall]

On Thu, Sep 30, 2010 at 5:26 PM, Max Funk  wrote:
> Hello,
>
> I wanted to report a problem with the cygwin uninstallation:
>
> If I delete the folder cygwin on my PC (Windows 7, 32 bit),
> as described in the FAQ "Cygwin uninstall", then there is
> remaining a special file
>
> C:\cygwin\dev\nul
>
> This file cannot be deleted afterwards from windows
> (at least, I didn't find any possibility.)
>

The last time I had to uninstall cygwin this was not a problem for me.

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

Cygwin uninstall: Problem with /dev/nul

[Max Funk]

Hello,

I wanted to report a problem with the cygwin uninstallation:

If I delete the folder cygwin on my PC (Windows 7, 32 bit), 
as described in the FAQ "Cygwin uninstall", then there is 
remaining a special file 

C:\cygwin\dev\nul

This file cannot be deleted afterwards from windows
(at least, I didn't find any possibility.) 

So I wanted to post the following information:
In my case (no warranty) the solution was as follows:
For a clean uninstall of cygwin, FIRST delete this file

cd /dev
rm -f nul

then exit cygwin, delete the cygwin folder (as described in the FAQ).

Maybe this should be verified and then inserted into the Cygwin FAQ:
How to uninstall Cygwin.


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

R: for Cygwin?

[Marco Atzeri]

--- Gio 30/9/10, Jan Chludzinski  ha scritto:

> After doing some web searches for
>  and Cygwin, I found
> there doesn't seem to be any support unless I use: gcc
> -I/usr/include/mingw -lm tc.c  But I still end up with:
> 
> /cygdrive/c/DOCUME~1/JOHNC~1.ECS/LOCALS~1/Temp/ccAPGnIv.o:tc.c:(.text+0x3d):
> undefined reference to `_ccos'
> collect2: ld returned 1 exit status
> 
> I'm really not interested in working with MinGW either.
>  All the
> messages about  and Cygwin are rather old
> (<2007) so I was
> hoping that 1.7 would remedy the problem.  Evidently not?
> 
> ---John
> 

John,
newlib (cygwin libc-like library) has not the complex type,
however on cygwin complex numbers are supported by 
the gcc/g++ compiler

/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/complex.h

what are exactly your needs ?

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

for Cygwin?

[Jan Chludzinski]

After doing some web searches for  and Cygwin, I found
there doesn't seem to be any support unless I use: gcc
-I/usr/include/mingw -lm tc.c  But I still end up with:

/cygdrive/c/DOCUME~1/JOHNC~1.ECS/LOCALS~1/Temp/ccAPGnIv.o:tc.c:(.text+0x3d):
undefined reference to `_ccos'
collect2: ld returned 1 exit status

I'm really not interested in working with MinGW either.  All the
messages about  and Cygwin are rather old (<2007) so I was
hoping that 1.7 would remedy the problem.  Evidently not?

---John

--
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: mintty window won't open

[Andy Koppe]

On 29 September 2010 09:49, Bengt-Arne Fjellner wrote:
>>> I think you can detect this situation (no access to the interactive
>>> desktop
>>> or whatever is it called), if you wished to issue a suitable error
>>> message,
>>> by checking that OpenInputDesktop() returns non-NULL...
>>
>> Good idea, and that does seem to do the job.
>>
>> Opening a window in that situation seems to work fine anyway though. I
>> guess it goes to some hidden desktop. Can anyone think of a sensible
>> use case for that, i.e. should I make this a warning rather than an
>> error?
>>
> I have a feeling it could be useful someway. Why not a command switch:
> --allow_null_desktop or something?

Because there's a good chance that no-one would ever need it. ;)

I'll make this a warning (or possibly just leave it).

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

Need Cygwin maintainer for Icarus Verilog and GTKWave

[Cary R.]

I am one of the Icarus Verilog developers and I'm looking for someone
to be the maintainer for both Icarus Verilog and GTKWave. I regularly
compile both of these under cygwin so they should already compile
out of the box. What I don't have time for is to monitor the main
cygwin list looking for user problems.

Icarus Verilog is a logic simulator that implement most of the
hardware description language Verilog (IEEE std 1364-2005).
GTKWave is a waveform viewer that supports many different
waveform formats.

The ideal maintainer would have some familiarity with Verilog, but I
would not consider that a requirement. Both tools are available from
various Linux distributions. There are currently MinGW compiled
binaries available. For portability and speed reasons these are the
projects preferred Windows solution, but having them available from
"setup" would be useful to Cygwin user working on smaller projects
where the speed difference is not a concern. The Cygwin version
also produces results that exactly match what is produced under
Linux.They probably belong with ngspice in the Science category.

I'm willing to provide help as needed.

Regards,

Cary R.



  

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

bash bug?: nested "bash --login -i" doesn't run /etc/profile (still runs ~/.bash_profile)

[Daniel Barclay]

The behavior of "bash --login -i" seems to vary depending on whether
it is a "root" invocation or a nested invocation of bash.  This is
inconsistent with the description man bash, and seems to be a bug.


Details:


When bash is started using the Cygwin shortcut (which runs cygwin.bat,
which executes "bash --login -i"), bash reads files /etc/profile and
~/.bash_profile.  (Running "bash --login -i" from an interactive
"cmd" shell does the same.)

However, when in that first bash process, another bash is started with
that same "bash --login -i" command, bash does _not_ read /etc/profile.

Interestingly, that nested bash shell _does_ still read
~/.bash_profile.

According to the bash manual page, "bash --login -i" should read
/etc/profile in either case.  (There is no mention of anything, e.g.,
an environment variable from the context of the invocation, that
changes the behavior of that command.)


An additional symptom is that the nested bash does not listen to
SHELLOPTS as expected:

A root invocation notices "igncr", "verbose", and "xtrace" in the
SHELLOPTS value from its invocation environment (the Windows/cmd
environment variable) as specified--it ends up setting SHELLOPTS in
itself to a value that includes those options.

On the other hand, a nested invocation seems to ignore the SHELLOPTS
from its invocation environment (the environment variable from the
first bash shell/process)--it sets its SHELLOPTS to a value that does
_not_ include those options.)


Steps to reproduce (and easily see difference):

1. Set Windows environment variable SHELLOPTS to
   "igncr:verbose:xtrace".
2. Start bash using the installer-created Cygwin shortcut.
3. Notice (from the output from the "verbose" and "xtrace" options)
   that bash runs /etc/profile and then ~/.bash_profile.
4. Notice (from "set") that SHELLOPTS in bash includes "igncr",
   "verbose" and "xtrace" (among other options).
5. Execute "bash --login -i".
6. Notice (again, from the verbose/xtrace output) that bash does
   _not_ run /etc/profile, but still runs ~/.bash_profile.
7. Notice that SHELLOPTS in that invocation of bash does not include
   "igncr", "verbose" or "xtrace".

It seems that something is going wrong between the points at which bash
reads SHELLOPTS and runs /etc/profile and the point at which bash runs
~/.bash_profile.



Daniel







(user name -> "username")
(Windows/DNS domain name -> "somedomain")


Cygwin Configuration Diagnostics
Current System Time: Thu Sep 30 13:21:26 2010

Windows XP Professional Ver 5.1 Build 2600 Service Pack 3

Path:   C:\tools\cygwin\usr\local\bin
C:\tools\cygwin\bin
C:\tools\cygwin\bin
C:\Username\bin
C:\tools\jdk1.6.0_21\bin
C:\tools\apache-ant-1.7.1\bin
C:\tools\emacs-23.2\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\system32\WindowsPowerShell\v1.0
C:\Program Files\Microsoft SQL Server\80\Tools\Binn\
C:\tools\cygwin\bin

Output from C:\tools\cygwin\bin\id.exe
UID: 12734(username)   GID: 10513(Domain Users)
10513(Domain Users)  0(root)  544(Administrators)
545(Users)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

USER = 'username'
PWD = '/c/Username'
HOME = '/c/Username'

HOMEPATH = '\Documents and Settings\username'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man:'
APPDATA = 'C:\Documents and Settings\username\Application Data'
HOSTNAME = 'november'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 4 Stepping 1, GenuineIntel'
HISTSIZE = '5000'
WINDIR = 'C:\WINDOWS'
IGNOREEOF = '10'
OLDPWD = '/usr/bin'
USERDOMAIN = 'SOMEDOMAIN_MAIN'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
ANT_HOME = 'C:\tools\apache-ant-1.7.1'
HISTFILESIZE = '5000'
TEMP = '/c/DOCUME~1/username/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
CYGWIN_BIN = 'C:\tools\cygwin\bin'
USERNAME = 'username'
PROCESSOR_LEVEL = '15'
PSModulePath = 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\'
SHELLOPTS = 
'braceexpand:emacs:hashall:histexpand:history:ignoreeof:interactive-comments:monitor:verbose:xtrace'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
JAVA_HOME = 'C:\tools\jdk1.6.0_21'
LANG = 'C.UTF-8'
USERPROFILE = 'C:\Documents and Settings\username'
CLIENTNAME = 'Console'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\VA-DC01'
PROCESSOR_ARCHITECTURE = 'x86'
!C: = 'C:\tools\cygwin\bin'
DSB_PROFILES_SOURCED = 't'
SHLVL = '1'
USERDNSDOMAIN = 'SOMEDOMAIN.COM'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1'
HOMEDRIVE = 'C:'
ANT_ARGS = '-emacs -find build.xml'
PROMPT = '$P$G'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/c/DOCUME~1/username/LOCALS~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
USERNAME_BIN = 'C:\Username\bin'
PRINTER = '\\VA-FS05\HP4200DTN'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '0401'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files'
NUMBER_OF

CYGWIN=noglob remove double quotes from args.

[Oleksandr Gavenko]

As I understand docs if I set CYGWIN=noglob then command line arguments
passed to Cygwin app WITHOUT changes.

I use native Emacs build so worry about stop Cygwin damage passed arguments.

And seems this is not true.

With CYGWIN=noglob all double quotes removed from args!

Originally I discaver this when I call Cygwin application from NT Emacs by:

  (call-process "bash" nil t nil "-c" "  echo \"ab\"  ")

I get: a b (ONE space!)

I wrote simple app that print its args quoted:

(call-process "printarg" nil t nil "-c" "echo \"a  \"\"\"\"  b\"\"\"\"\"")

"/cygdrive/d/home/usr/bin/printarg"
"-c"
"echo ab"

If compile printarg.c with MSVC all quotes printed:

(call-process "printarg" nil t nil "-c" "echo \"a  \"\"\"\"  b\"\"\"\"\"")

"/cygdrive/d/home/usr/bin/printarg"
"-c"
"echo "a    b""

Same happen with cmd.exe:

cmd# printarg-msvc  "a \" b"
"printarg-msvc.exe"
"a " b"

cmd# set CYGWIN=glob
cmd# printarg-cygwin  "a \" b"
"printarg"
"a " b"

cmd# set CYGWIN=noglob
cmd# printarg-cygwin  "a \" b"
"printarg"
"a \"
"b"


--
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: use the list of files stored in a text file and process it

[Brian Wilson]

> I store a list of files in a text file (test.txt) on Windows XP.
> I want to use the list of files and process it (e.g. ls).
> What is the command to do that?
> I tried the following commands but to no avail.
> 
> $ cat test.txt
> test.txt
> 
> $ cat test.txt | xargs ls
> : No such file or directory
> 
snip...

Try something like "cat test.txt | xargs -i ls {}" or "cat test.txt | xargs -t 
ls" I suspect the first one will work for you and the second one will show you 
the command line before running the command (to help you debug in future).

Sincerely,

Brian S. Wilson


--
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: diff issue

[Brian Wilson]

> Greetings, All!
> 
> I have strange (to me) issue that I'm not entirely sure how to interpret.
> 
> Let's say I have two versions of the same batch file:
> 
> The old version from CVS:
> 
> > rem $Id: backup.bat,v 1.1 2007/07/17 01:53:30 Daemon Exp $
> > rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list
> 
> The new version I've imported to Subversion:
> 
> > @echo off
> > rem $Id: backup.bat 10 2010-09-30 01:22:14Z anrdaemon $
> > rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list
> 
> When I'm comparing them with my usual macro
> diff -bdu -x "CVS" -x ".svn" -I "\$Id.*\$" -I "\$Revision.*\$" -I 
> "\$Date.*\$" -I "\$Author.*\$" --strip-trailing-cr -- '1/backup.bat' 
> 'backup.bat'
> 
> It telling me that $Id$ lines are differ.
> But when I remove the "@echo off" from second file, it telling me 
> that files are "identical" (the expected result).
> 
> Having hard times dechiphering man diff, so if anyone can enlighten 
> me in simple words on the matter, I'd appreciate help greatly.
> 
> -- 
> WBR,
>  Andrey Repin 30.09.2010, <5:33>
> 
> Sorry for my terrible english...
> 

Be sure the end of line characters are correct on the "@echo" line.  You 
should be able to do this with a "cat -vTE" command.  (sorry for my terrible 
Russian)

Убедитесь, 
что конец 
строки 
символы 
правильно на 
"@echo" линии. Вы 
должны быть 
в состоянии 
сделать это с 
помощью "cat -vTE" 
команды. 
(Извините за 
мой ужасный 
русский)

Sincerely,

Brian S. Wilson

--
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: error: "unable to remap" - despite repeated rebaseall

[Reini Urban]

2010/9/29 Mike Slass:
> The system:
>  Windows Server 2008 x86_64
>  perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int
>    (with 12 registered patches, see perl -V for more detail)
>  cygwin-1.7
>
>
> The error:
>
>      5 [main] perl 19364 fork: child 19100 - died waiting for dll loading, 
> errno 11
> 5071704 [main] perl 18988 C:\bin\perl.exe: *** fatal error - unable to remap 
> \\?\C:\lib\perl5\site_perl\5.10\i686-cygwin\auto\P4\P4.dll to same address as 
> parent: 0xA7 != 0x143
> Stack trace:
> Frame     Function  Args
> 0088B458  610274AB  (0088B458, , , )
> 0088B748  610274AB  (61177840, 8000, , 61178977)
> 0088C778  61004ADB  (611A034C, 6123E3D4, 00A7, 0143)
> End of stack trace
>
>
> Additional background:
>
> P4.dll is part of a perl extension library for Perforce, p4perl.  I built  
> the perl library from source, but it links with some pre-compiled libraries 
> that come from Perforce.  Those libraries *were* built for cygwin.
>
> The P4.pm perl extension would not build with gcc 4, so when I built it I 
> used g++-3 for the compiler and linker.
>
>
> I have tried running rebaseall several times, all successfully.  I have 
> provided an additional filelist to rebaseall (with -T) to make sure that the 
> P4.dll was included in the rebaseing, since the P4.dll was not installed by 
> cygwin, so is not listed as an installed file.
>
> Any suggestions?

Sure, perlrebase (now also with man page)

And if P4 depends on new dll's which are not under
/usr/lib/perl/*/auto than you'll have to
add your new dll's also to the intermediate rebase.lst which
perlrebase creates for you in the current dir, and use rebase with -T
rebase.lst

rebaseall just rebases official cygwin package dll's, not any user dll's.
-- 
Reini Urban

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

does the `notexec' mount option influence file access performance on a server?

[Mirko Vukovic]

Hello,

I have the following /etc/fstab entry

//server/mirko/ /z dont_care binary,posix=0,user,noacl,notexec 0 0

for a server directory where I store my backups.  I will not be using
any of those files as executables.  I have cygwin running on my
desktop.

The manual states that the `exec' option avoids the overhead of
opening each file to determine whether it is an executable or not.

Will the notexec option also improve reduce the overhead?

Thanks,

Mirko

--
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-4.5 + gdb dwarf problems

[Reini Urban]

2010/9/30 Reini Urban:
> I think I've found an issue with the new gcc-4.5 with latest gdb.

> Program received signal SIGSEGV, Segmentation fault.
> 0x0068391b in Perl_pad_undef (cv=0x24a3d60) at pad.c:138
> 138         PERL_ARGS_ASSERT_PAD_PEG;
>
> If linked to the dll the cv argument is missing.
>
> And the correct src line is pad.c:256, not pad.c:138
>  objdump -S -gl ccode27_o2.exe|^egrep -7 ^Perl_pad_undef

I've crosschecked with mingw gdb-7.1 and the linenumber
looks better there.

Just the arguments for functions inside the dll are also not displayed:

Program received signal SIGSEGV, Segmentation fault.
0x54a4d00b in Perl_pad_undef ()
   from D:\cygwin\usr\local\bin\cygperl5_13_5d...@1fdb04e0.dll

vs.
Program received signal SIGSEGV, Segmentation fault.
0x00552f6b in Perl_pad_undef (cv=0x2323d60) at pad.c:290
290 && *SvPVX_const(namesv) == '&')

-- 
Reini Urban
http://phpwiki.org/           http://murbreak.at/

--
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: R: Cygwin 1.7.7 fork/exec performance MUCH slower than 1.5.25

[Christopher Faylor]

On Thu, Sep 30, 2010 at 09:10:48AM -0400, Edward Lam wrote:
>> testing on /tmp/benchmark with XPS P2
>>
>> cygwin 1.7.8s 20100924
>
>You're testing on the latest snapshot against his cygwin 1.7.7 results. 
>This gives me hope that Cygwin can become faster because Sagi Ben-Akiva 
>was willing to track down the cause of the slowdown [1]. Last I read, 
>it's not clear whether the latest CVS changes are faster though [2]. 
>However, it's probably worth trying out the 20100926 snapshot.
>
>We haven't mentioned yet whether we are running under 32-bit or 64-bit 
>Windows. It would be useful to know whether the problem only affects 
>64-bit Windows or not. Looking at the code changes, I would have thought 
>it would equally affect 32-bit Windows.

32-bit Windows is basically unchanged.

--
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: use the list of files stored in a text file and process it

[Larry Hall (Cygwin)]

On 9/30/2010 9:37 AM, SJ Wright wrote:

I know one of the trip-ups I often have if I spend any time away from a
L/Unix environment has to do with the "mv" command: I often forget that it
prefers absolute paths from root folders (or in the case of Cygwin, virtual
ones taken as real) or dot-dot-slash relative path syntax to just
"/god-directory/" or what-have-you. Many other commands, particularly ls and
ln -s, are likewise "particular about their paths."


That's a sweeping statement without any supporting data.  I guess all I
can say is that my experience doesn't coincide with your statements.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


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

gcc-4.5 + gdb dwarf problems

[Reini Urban]

Hi
I think I've found an issue with the new gcc-4.5 with latest gdb.

I only experience these problems in the gdb debugger, when the
sourceline for the function is wrong,
but inspecting the dwarf output, esp the line info via objdump -Wl looks good.
objdump -Sgl also looks good.

objdump: The path of the source files resolves to something wrong in
objdump -Wl.

gdb: If linked with a library as dll  (cygperl.dll in my case) the
arguments are not displayed in the debugger,
if linked to a static .a or .o, the arguments are displayed okay.

E.g. debugging perl linked to the static libperl.a like
gcc-4 -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -march=pentium4
-mfpmath=sse -mieee-fp -mmmx -msse -msse2 -DDEBUGGING
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
-I/usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/CORE -g3
ccode27_o2.c -o ccode27_o2-Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--stack,8388608
-Wl,--enable-auto-image-base -fstack-protector -L/usr/local/lib
/usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/auto/Win32CORE/Win32CORE.a
/usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/CORE/libperl.a
/usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/CORE/DynaLoader.a
-ldl -lcrypt
=>

objdump -WL -S -gl ccode27_o2.exe|less

CU: /usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/CORE/ccode27_o2.c:
but the /ccode27_o2.c is in ./, the line info is correct here. I can
debug into it fine.
next obj is
CU: /usr/include/sys/gv.c:
File nameLine numberStarting address
gv.c  450x406f98

And this is in /usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/CORE/
not in /usr/include/sys/

$ gdb ccode27_o2.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 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.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run
Starting program: /cygdrive/d/data/urbanr/My
Documents/Perl/B-C-work/ccode27_o2.exe
[New thread 1988.0x116c]
[New thread 1988.0x1358]
ok
Program received signal SIGSEGV, Segmentation fault.
0x0068391b in Perl_pad_undef (cv=0x24a3d60) at pad.c:138
138 PERL_ARGS_ASSERT_PAD_PEG;

If linked to the dll the cv argument is missing.

And the correct src line is pad.c:256, not pad.c:138
 objdump -S -gl ccode27_o2.exe|^egrep -7 ^Perl_pad_undef

00683785 <_Perl_pad_undef>:
Perl_pad_undef():
/usr/src/perl/blead/buildntdebug/pad.c:256
=cut
*/

void
Perl_pad_undef(pTHX_ CV* cv)
{


-- 
Reini Urban
http://phpwiki.org/           http://murbreak.at/

--
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: use the list of files stored in a text file and process it

[SJ Wright]

albert kao wrote:

I store a list of files in a text file (test.txt) on Windows XP.
I want to use the list of files and process it (e.g. ls).
What is the command to do that?
I tried the following commands but to no avail.

$ cat test.txt
test.txt

$ cat test.txt | xargs ls
: No such file or directory

$ cat test.txt | xargs -delimiter="\n" ls
xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be 
either a single char

acter or an escape sequence starting with \.

$ cat test.txt | xargs -delimiter='\n' ls
xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be 
either a single char

acter or an escape sequence starting with \.

$ cat test.txt | xargs -delimiter='\\n' ls
xargs: Invalid input delimiter specification elimiter=\\n: the delimiter must be 
either a single cha

racter or an escape sequence starting with \.

$ cat test.txt | xargs -delimiter="\\n" ls
xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be 
either a single char

acter or an escape sequence starting with \.

$ uname -srv
CYGWIN_NT-5.1 1.7.5(0.225/5/3) 2010-04-12 19:07



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


  
I would also suggest that you check your filenames in test.txt to make 
sure, if you included paths, that they are absolute and follow the 
Cygwin virtual-paths (cygpath) syntax, i.e.: /cygdrive/c/... or 
/etc/share/... and so on. Barring that, a path in Unix notation relative 
to your $PWD -- or the directory where test.txt is saved -- is a good 
starting point (npi): something along the lines of bin/deprecated or 
../man1 .


I know one of the trip-ups I often have if I spend any time away from a 
L/Unix environment has to do with the "mv" command: I often forget that 
it prefers absolute paths from root folders (or in the case of Cygwin, 
virtual ones taken as real) or dot-dot-slash relative path syntax to 
just "/god-directory/" or what-have-you. Many other commands, 
particularly ls and ln -s, are likewise "particular about their paths."


Steve W.


--
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: R: Cygwin 1.7.7 fork/exec performance MUCH slower than 1.5.25

[Edward Lam]

testing on /tmp/benchmark with XPS P2

cygwin 1.7.8s 20100924


You're testing on the latest snapshot against his cygwin 1.7.7 results. 
This gives me hope that Cygwin can become faster because Sagi Ben-Akiva 
was willing to track down the cause of the slowdown [1]. Last I read, 
it's not clear whether the latest CVS changes are faster though [2]. 
However, it's probably worth trying out the 20100926 snapshot.


We haven't mentioned yet whether we are running under 32-bit or 64-bit 
Windows. It would be useful to know whether the problem only affects 
64-bit Windows or not. Looking at the code changes, I would have thought 
it would equally affect 32-bit Windows.


1. http://cygwin.com/ml/cygwin/2010-08/msg00964.html
2. http://cygwin.com/ml/cygwin/2010-09/msg00796.html

Regards,
-Edward

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

R: Cygwin 1.7.7 fork/exec performance MUCH slower than 1.5.25

[Marco Atzeri]

--- Gio 30/9/10, SZABÓ Gergely  ha scritto:

> Hello,
> 
> we have a Cygwin-based build system for an embedded
> project.
> Build performance has deteriorated terribly since we
> upgraded to 1.7.x from 1.5.25.
> 
> I've created 3 shell-scripts to benchmark 1.5.25 and 1.7.7
> against each other.
> - null    : read file "inp" line by line, write
> to /dev/null.
> - builtin : write each line to file "out", only
> bash-builtins used (no fork)
> - fork    : do some substitution for each line
> with sed (huge number of forks)
> 
> Results:
> - null    : 1.7.7 is about 5 times faster
> - builtin : 1.7.7 is slightly faster
> - fork    : 1.7.7 is 5 times SLOWER !!!
> 
> All measurements were made with the "time" command.
> The attached results.txt lists the "real" times.
> 
> I've also attached the 3 shell-scripts (null, builtin,
> fork).
> Input file "inp" is also attached.
> 
> Also see the cygcheck_xxx.out files for both Cygwin
> versions.
> 
> Some notes: 
> both cygwin versions use the same /home, mounted from
> "D:\Documents and Settings",

I bet is a network/acl issues. 
I suggest to create a real home on "/home"

> so all user-level config-files are shared between the
> Cygwin versions.
> 
> Cygwin 1.7.7 is basically unusable at the moment.
> Any ideas why it's so much slower at spawning processes? Or
> is it the pipes? Am I doing something wrong?
> 
> And more importantly: is there an easy way to fix this?
> 
> Thanks in advance for any help!
> 
> Best regards
> Gergely Szabó
> 

testing on /tmp/benchmark with XPS P2

cygwin 1.7.8s 20100924

$ time ./fork

real1m12.856s
user0m52.480s
sys 1m6.423s


cygwin 1.5.25-15

$ time ./fork

real1m7.969s
user0m52.992s
sys 1m11.583s


So no difference

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: use the list of files stored in a text file and process it

[Henry S. Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

You will also run into problems with xargs and filenames with spaces
in.  In my experience, the simplest thing that works reliably with
xargs and all Windoz filenames is xargs -0, so what you want is

> tr -s '\012\015' '\000' < test.txt | xargs -0 ls

Note also that find has a -print0 flag, which goes well with -0

> find . -name '[whatever]' ... -print0 | xargs -0 ...

ht
- -- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFMpEHTkjnJixAXWBoRAvcjAJ4uo9c819hzVbbVovyTN8z4+/g2HQCfShCC
pFsvAO0QacPuXcIQjsKqWVY=
=9ZJi
-END PGP SIGNATURE-

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