Re: Fixing the state of C++ in Cygwin

[Angelo Graziosi]

Steven Brown wrote:


> I could build the packages and fix the sh/diff this weekend given a call
> on which path to take - draft patch or --enable-fully-dynamic-string. I
> just don't want it to fall through the cracks again 


This would be very appreciated!

If your request is not accepted, may you put some links from which we (not
very expert in this things) can download your work?


Thanks,

   Angelo.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Resizing images from CLI

[zzapper]

>From the talk NG I got this info for CLI image manipulation

requires ImageMagick installed and in path

# from imageMagick

convert -sample 80x40 abbeyparkarch.gif s_abbeyparkarch.gif
lsimg abbeyparkarch.gif s_abbeyparkarch.gif

What I'd like now is to resize an image but preserve it's aspect ratio

how do?

-- 
http://successtheory.com/tips/ Vim, Zsh, MySQL Tips


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How do I detect a failure in Make?

[Richard Quadling]

On 26/04/06, mwoehlke <[EMAIL PROTECTED]> wrote:
> Richard Quadling wrote:
> > I have the following bash script ...
> >
> > #!/bin/sh
> > cvs up 2> $HOME/cvs1.log > $HOME/cvs2.log
> > cd phpdoc
> > autoconf -v -d --warnings=all &> $HOME/autoconf.log
> > ./configure --with-source=./../php-src --with-pear-source=./../pear
> > --with-chm=yes --with-treesaving > $HOME/configure.log
> > make test > $HOME/make_test.log
> > make test_xml > $HOME/make_test_xml.log
> > make chm_xsl > $HOME/make_chm_xsl.log
> >
> > Is there a way of stopping the makes if there was a problem.

> Matthew said using [ $? -eq 0 ] || exit $? after each make line would work.

It doesn't. The issue is that the make function is crashing (the core
dump ??!!!??).

I'm not responsible for the construction of the make file, I just want
to stop my script from running if there is a problem.

--
-
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=UlF1YWRsaW5n

Re: Call for testing Cygwin snapshot

[Danilo Turina]

Christopher Faylor wrote:

On Thu, Apr 27, 2006 at 03:38:27PM +0200, Danilo Turina wrote:
No, sorry: I'm not using a snapshot. I thought you intended to say that 
/bin/pwd would have failed also with the current version.


Then please choose another thread to discuss any issues not involved with
the Cygwin snapshot.

cgf

No, there's no issue at all in the stable versione, only a little 
misunderstading: I (wrongly) understood (from a previous message) that a 
problem present in the stable version was also present in the snapshot.


Verifying that the stable version (of my Cygwin installation) was immune 
to that problem I notified this information in the aim of helping the 
debugging of the snapshot.


Ciao,

Danilo


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Suggestions for caching only DNS server to run on CygWin

[David Arnstein]

On Thu, Apr 27, 2006 at 08:28:20PM -0500, Herb Martin wrote:
> Suggestions for caching only DNS server to run on CygWin

If you are looking for a relay DNS server, consider dnrd. Look it up on
Sourceforge. It is ported to cygwin (I helped!).

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync over ssh hang issue understood

[Corinna Vinschen]

On Apr 27 20:15, Steven Hartland wrote:
> - Original Message - 
> From: "Christopher Faylor" <[EMAIL PROTECTED]>
> 
> > "Search for cygwin1.dll using the Windows Start->Find/Search facility
> > and delete all but the most recent version.  The most recent version 
> > *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have
> > installed the cygwin distribution.  Rebooting is also suggested if you
> > are unable to find another cygwin DLL."
> 
> Stupid me, perl.exe still running in the background using the old .dll.
> Things now run by unfortunately rsync is still hangs virtually
> instantly :(
> 
> [log]
> rsync -av --progress cygwin1:/testdir/ testdir/ 
> receiving file list ... 
> 1705 files to consider
> created directory testdir
> ./
> bf2_w32ded.exe
> ***HUNG HERE***
> ^CKilled by signal 2.0.00kB/s0:00:00
> rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(242) 
> [receiver]
> rsync error: unexplained error (code 255) at rsync.c(242) [generator]
> [/log]

Damn (sorry).

It works fine for me with the latest snapshot.  I tried Peter's example
with 1000 files and rsync over ssh works like a charm for me.  Sigh.

This is really a tricky problem.  What I could do to circumvent this at
least for connections over ssh is to upload an OpenSSH test version
which uses socketpairs instead of pipes for the local connection to the
applications.  This avoids using pipes which are the culprit here,
apparently.I would mark it as experimental version, but actually the
only difference would be that it would be a few per cent slower than the
version using pipes.  And that it probably doesn't hang.

Is there interest in such a version?


Corinna

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cygwin build error

[Corinna Vinschen]

This is a newlib problem.  I've redirected this mail to the appropriate
list newlib AT sourceware DOT org.

On Apr 27 15:14, Ernie Coskrey wrote:
> I ran into the following problem building the latest cygwin snapshot:
> 
> configure: loading cache .././config.cache
> configure: error: `CFLAGS' has changed since the previous run:
> configure:   former value:  -O2 -g -O2  
> configure:   current value: -O2 -g -O2 
> configure: error: changes in the environment can compromise the build
> configure: error: run `make distclean' and/or `rm .././config.cache' and 
> start over
> configure: error: /bin/sh '../../../../src/newlib/libc/configure' failed for 
> libc
> 
> By piping the output to a file, I saw that the former value of CFLAGS is "-O2 
> -g -O2  " (two spaces), while the current value is "-O2 -g -O2 " (one space). 
>  This causes the comparison in libc/configure to fail.
> 
> The way I've resolved this is to replace the following line:
> 
>   if test "x$ac_old_val" != "x$ac_new_val"; then
> 
> with
> 
>   if test "`echo $ac_old_val`" != "`echo $ac_new_val`"; then
> 
> wherever it appears in any "configure" script (there are 75 configure scripts 
> that contain this test, BTW).  There may be a more elegant way around this, 
> but I haven't found it.  Running "make distclean" or removing config.cache 
> doesn't resolve the problem.
> 
> -
> Ernie Coskrey   SteelEye Technology, Inc.803-461-3875


Corinna

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync over ssh hang issue understood

[Brett Serkez]

This is really a tricky problem.  What I could do to circumvent this at
least for connections over ssh is to upload an OpenSSH test version
which uses socketpairs instead of pipes for the local connection to the
applications.  This avoids using pipes which are the culprit here,
apparently.I would mark it as experimental version, but actually the
only difference would be that it would be a few per cent slower than the
version using pipes.  And that it probably doesn't hang.


It has been so long since I gave up on this that I forgot building my
own version of rsync to do exactly this.

I've noticed multiple postings indicating issues with pipes.  Wouldn't
it be better to track this down, it would likely fix multiple
problems.

Brett

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cygwin server sends the same key fingerprint all the time

[Soumya]

Hi,

 thank you very much for replying and aplologies for my newbieness. (that was 
the cygcheck -v
output I mentioned earlier, I am attaching the whole cygcheck output here at 
the end of this mail
now).
 I have tried to get some info on the net to solve my questions, but have 
failed. 
 As I mentioned in the description below, I still have this problem of 
receiving the same key
fingerprint from the host whatever new public key I append to authorized_keys1 
(and
authorized_keys) file. 

I create a new public/private key pair on my client, copy public key to 
authorized_keys file, copy
public key details to client known_hosts file and using j2ssh API, connect to 
host, I get the
following message :

The host key fingerprint is: 1030: b2 49 71 88 9d 6 5e e0 c1 97 52 1 be b6 da a7
Do you want to allow this host key? [Yes|No|Always]:

No matter what new key pair I use, I get the same fingerprint on the client.

I do stop (cygrunsrv --stop sshd) and start (cygrunsrv --start sshd) after a 
new key pair process.

I would like to know where cygwin loads the keys from. 

many thanks in advance,
Soumya

---

Cygwin Configuration Diagnostics
Current System Time: Fri Apr 28 12:05:00 2006

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   D:\Apps\Cygwin\usr\local\bin
D:\Apps\Cygwin\bin
D:\Apps\Cygwin\bin
c:\Programme\TCL8.4.1.0\bin
c:\WINNT\system32
c:\WINNT
c:\WINNT\System32\Wbem
d:\Apps\NetBeans\j2sdk1.4.2\bin
d:\apps\apache-ant-1.6.0\bin
d:\apps\Perforce
d:\apps\iText
D:\Apps\Cygwin\bin
c:\Programme\Rational\common
c:\Programme\EasyPHP1-7\mysql\bin

Output from D:\Apps\Cygwin\bin\id.exe (nontsec)
UID: 500(Administrator) GID: 513(None)
0(root) 513(None)   544(Administratoren)
545(User)

Output from D:\Apps\Cygwin\bin\id.exe (ntsec)
UID: 500(Administrator) GID: 513(None)
0(root) 513(None)   544(Administratoren)
545(User)

SysDir: C:\WINNT\system32
WinDir: C:\WINNT

USER = `Administrator'
PWD = `/home/Administrator'
CYGWIN = `ntsec tty'
HOME = `/home/Administrator'
MAKE_MODE = `unix'

HOMEPATH = `\Dokumente und Einstellungen\Administrator'
MANPATH = `:/usr/ssl/man'
APPDATA = `C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten'
TERM = `cygwin'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 7 Stepping 3, GenuineIntel'
WINDIR = `C:\WINNT'
TISDIR = `C:\Programme\Rational\common'
OLDPWD = `/usr/bin'
USERDOMAIN = `PC-ARMN'
OS = `Windows_NT'
ALLUSERSPROFILE = `C:\Dokumente und Einstellungen\All Users'
ANT_HOME = `d:\apps\apache-ant-1.6.0'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
TEMP = `/cygdrive/c/DOKUME~1/ADMINI~1/LOKALE~1/Temp'
COMMONPROGRAMFILES = `C:\Programme\Gemeinsame Dateien'
IBMLDAP_ALTHOME = `C:\Programme\Rational\common\codeset'
RATL_RTHOME = `C:\Programme\Rational\Rational Test'
USERNAME = `Administrator'
NUTSUFFIX = `1'
PROCESSOR_LEVEL = `6'
SYSTEMDRIVE = `C:'
JAVA_HOME = `C:\Programme\Java\j2re1.4.2_01'
USERPROFILE = `C:\Dokumente und Einstellungen\Administrator'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
LOGONSERVER = `\\PC-ARMN'
PROCESSOR_ARCHITECTURE = `x86'
!C: = `C:\Dokumente und Einstellungen\Administrator\Desktop'
SHLVL = `1'
RWPHOME = `C:\Programme\Rational\common\rwp'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl'
ITEXT_HOME = `d:\apps\iText'
HOMEDRIVE = `C:'
!D: = `D:\Apps\Cygwin\bin'
NUT_SUFFIXED_SEARCHING = `1'
PROMPT = `$P$G'
COMSPEC = `C:\WINNT\system32\cmd.exe'
TMP = `/cygdrive/c/DOKUME~1/ADMINI~1/LOKALE~1/Temp'
SYSTEMROOT = `C:\WINNT'
PROCESSOR_REVISION = `0703'
CLASSPATH =
`;C:\Programme\Java\j2re1.4.2_01\jaxp.jar;D:\Apps\NetBeans\j2sdk1.4.2\jre\lib;d:\apps\iText\iText.jar;d:\apps\iText\itext-xml-1.02.jar;'
PROGRAMFILES = `C:\Programme'
NUMBER_OF_PROCESSORS = `1'
COMPUTERNAME = `PC-ARMN'
_ = `/usr/bin/cygcheck'
POSIXLY_CORRECT = `1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `D:\Apps\Cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `D:\Apps\Cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `D:\Apps\Cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

a:  fd N/AN/A
c:  hd  NTFS 10503Mb  62% CP CS UN PA FC Part I
d:  hd  NTFS 28505Mb  41% CP CS UN PA FC Part II
e:  cd

Re: rsync over ssh hang issue understood

[Corinna Vinschen]

On Apr 28 06:25, Brett Serkez wrote:
> >This is really a tricky problem.  What I could do to circumvent this at
> >least for connections over ssh is to upload an OpenSSH test version
> >which uses socketpairs instead of pipes for the local connection to the
> >applications.  This avoids using pipes which are the culprit here,
> >apparently.I would mark it as experimental version, but actually the
> >only difference would be that it would be a few per cent slower than the
> >version using pipes.  And that it probably doesn't hang.
> 
> It has been so long since I gave up on this that I forgot building my
> own version of rsync to do exactly this.
> 
> I've noticed multiple postings indicating issues with pipes.  Wouldn't
> it be better to track this down, it would likely fix multiple
> problems.

Sure, you're welcome to do this.  It's not exactly a problem to track it
down, it's to find a working solution which is the problem.  I wouldn't
offer the above temporary workaround if we had a solution.

The low-level problem is this: Cygwin's select(2) on the write end of
pipes always returns that the pipe is writable, since nobody has found a
test for the writablility of Windows pipes, which actually works correct.
For details see cygwin's source, file select.cc, function peek_pipe.

http://cygwin.com/acronyms/#PTC


Corinna

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync over ssh hang issue understood

[Steven Hartland]

- Original Message - 
From: "Corinna Vinschen" <[EMAIL PROTECTED]>



Damn (sorry).

It works fine for me with the latest snapshot.  I tried Peter's example
with 1000 files and rsync over ssh works like a charm for me.  Sigh.

This is really a tricky problem.  What I could do to circumvent this at
least for connections over ssh is to upload an OpenSSH test version
which uses socketpairs instead of pipes for the local connection to the
applications.  This avoids using pipes which are the culprit here,
apparently.I would mark it as experimental version, but actually the
only difference would be that it would be a few per cent slower than the
version using pipes.  And that it probably doesn't hang.

Is there interest in such a version?


Yes I'd be very interested in testing this as its not only
rsync that suffers from this problem, other standard ssh
operations have been known to hang as well here.

It is the single biggest blocker on smooth cygwin operation
here and if its slightly slower that's a small price to pay
for correct operation.

   Steve



This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone (023) 8024 3137
or return the E.mail to [EMAIL PROTECTED]


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Geomview & Cygwin setup

[Lloyd Wood]

(adding in the geomview and cygwin lists.)

Chris,

Looking at the changes in:
http://cvs.sourceforge.net/viewcvs.py/geomview/geomview/src/bin/animate/glob.c
there are specific fixes for Cygwin portability that have been 
included in Geomview 1.8.2 alpha that affect d_ino use; try changing 
the sense of !defined(__CYGWIN__)  to just defined(__CYGWIN__)  and 
see if that works with your compiler. I imagine it will.


I see the output of gcc -v has changed in current cygwin:
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

It used to be just e.g.:
gcc version 3.3.3 (cygwin special)

cygming, not cygwin? ('ming' is a strong insult in the UK. I get the 
impression the writer doesn't like cygwin.) No idea what pre-release 
gdc or dmd are, or where they've come from, or why I should care about them.


It's awfully tempting to conclude that the compiler is screwing you 
around (because the compiler's authors have been screwing it around, 
because they hate Cygwin?), and you might want to to try an earlier 
version of that. I also wonder if __CYGWIN__ is being defined and 
picked up in the compiler environment correctly.


I'm actually running Geomview 1.8.1 and Geomview 1.8.2-alpha on top 
of cygwin base 1.5.19-4... but I compiled them on a much earlier 
cygwin with an earlier version of gcc, and on an entirely different 
machine that I recently migrated the files from. (I haven't tried 
recompiling, and your note suggests I would be unwise to.)


But I have compiled SaVi and Geomview on an earlier Cygwin;
http://cvs.sourceforge.net/viewcvs.py/savi/savi-dev/README?rev=1.36&view=markup
tells me the first base Cygwin I used successfully was 1.5.9-1, and 
also lists the successful versions of gcc.


cheers,

L.

> Hi Lloyd,
>
> I'm a masters student at UBC in Vancouver and I'm trying to get Geomview
> installed on my Windows machine. I'm following the instructions that
> you've posted via geomview.org but my 
compilation is running into an

> error. It seems in glob.c (in directory
> geomview-1.8.2-alpha/src/bin/animate) there is a reference to d_ino of
> the dirent structure. Now from my research into fixing this it seems
> that d_ino is not supported in version 1.5.19-4 but will be in 1.5.20, I
> also tried with version 1.5.8-1 with the same result. Do you know of any
> way I can get around this problem? I hope this is description is
> satisfactory, if you need any clarification please let me know.

Cheers,
Chris Elliott


<[EMAIL PROTECTED]> 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Dave Korn]

On 28 April 2006 12:30, Lloyd Wood wrote:


> cygming, not cygwin? ('ming' is a strong insult in the UK. 

  Yes, and we also do tongue-in-cheek humour quite well.  Well, at least some
of us do.

> I get the impression the writer doesn't like cygwin.) 

  Who precisely do you suppose "the writer" would have been?  Think hard
before answering: who could possibly have been responsible for writing the
cygwin port of gcc, used for compiling programs for cygwin?  Give up?  The
answer is "someone who would have to be a significant contributor to the
cygwin project".  It would be strange to think that someone would spend all
that time and effort doing unpaid voluntary work if they didn't like cygwin
quite a lot.  As a general guideline for logical reasoning, you should reject
any assumption you make that leads you to the conclusion that everyone else is
insane / stupid / irrational / entirely oblivious to their own best interests.
Occam's razor and all that.

> It's awfully tempting to conclude that the compiler is screwing you
> around (because the compiler's authors have been screwing it around,
> because they hate Cygwin?), 

  Well, then you are saying that ridiculous, paranoid, ludicrous conspiracy
theorising, based on zero information and even less research, is quite
tempting.  Now go away and find out what MinGW is and why cygwin's compiler
might want to refer to it.  Once you stop placing a superfluous emotional
colouring on the word you will be less distracted by irrelevancies and more
able to solve your bug rationally.  Stop spreading misinformed FUD.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Please ignore the previous mails re. - Re: cygwin server sends the same key fingerprint all the time

[Soumya]

Hi,

 please ignore the mail regarding the key fingerprint. We have found the 
solution to our problem,
namely the key lying in ssh_host_key file.

thanks and regards,
soumya.

--- Soumya <[EMAIL PROTECTED]> wrote:

> Hi,
> 
>  thank you very much for replying and aplologies for my newbieness. (that was 
> the cygcheck -v
> output I mentioned earlier, I am attaching the whole cygcheck output here at 
> the end of this
> mail
> now).
>  I have tried to get some info on the net to solve my questions, but have 
> failed. 
>  As I mentioned in the description below, I still have this problem of 
> receiving the same key
> fingerprint from the host whatever new public key I append to 
> authorized_keys1 (and
> authorized_keys) file. 
> 
> I create a new public/private key pair on my client, copy public key to 
> authorized_keys file,
> copy
> public key details to client known_hosts file and using j2ssh API, connect to 
> host, I get the
> following message :
> 
> The host key fingerprint is: 1030: b2 49 71 88 9d 6 5e e0 c1 97 52 1 be b6 da 
> a7
> Do you want to allow this host key? [Yes|No|Always]:
> 
> No matter what new key pair I use, I get the same fingerprint on the client.
> 
> I do stop (cygrunsrv --stop sshd) and start (cygrunsrv --start sshd) after a 
> new key pair
> process.
> 
> I would like to know where cygwin loads the keys from. 
> 
> many thanks in advance,
> Soumya
> 
> ---
> 
> Cygwin Configuration Diagnostics
> Current System Time: Fri Apr 28 12:05:00 2006
> 
> Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4
> 
> Path: D:\Apps\Cygwin\usr\local\bin
>   D:\Apps\Cygwin\bin
>   D:\Apps\Cygwin\bin
>   c:\Programme\TCL8.4.1.0\bin
>   c:\WINNT\system32
>   c:\WINNT
>   c:\WINNT\System32\Wbem
>   d:\Apps\NetBeans\j2sdk1.4.2\bin
>   d:\apps\apache-ant-1.6.0\bin
>   d:\apps\Perforce
>   d:\apps\iText
>   D:\Apps\Cygwin\bin
>   c:\Programme\Rational\common
>   c:\Programme\EasyPHP1-7\mysql\bin
> 
> Output from D:\Apps\Cygwin\bin\id.exe (nontsec)
> UID: 500(Administrator) GID: 513(None)
> 0(root) 513(None)   544(Administratoren)
> 545(User)
> 
> Output from D:\Apps\Cygwin\bin\id.exe (ntsec)
> UID: 500(Administrator) GID: 513(None)
> 0(root) 513(None)   544(Administratoren)
> 545(User)
> 
> SysDir: C:\WINNT\system32
> WinDir: C:\WINNT
> 
> USER = `Administrator'
> PWD = `/home/Administrator'
> CYGWIN = `ntsec tty'
> HOME = `/home/Administrator'
> MAKE_MODE = `unix'
> 
> HOMEPATH = `\Dokumente und Einstellungen\Administrator'
> MANPATH = `:/usr/ssl/man'
> APPDATA = `C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten'
> TERM = `cygwin'
> PROCESSOR_IDENTIFIER = `x86 Family 6 Model 7 Stepping 3, GenuineIntel'
> WINDIR = `C:\WINNT'
> TISDIR = `C:\Programme\Rational\common'
> OLDPWD = `/usr/bin'
> USERDOMAIN = `PC-ARMN'
> OS = `Windows_NT'
> ALLUSERSPROFILE = `C:\Dokumente und Einstellungen\All Users'
> ANT_HOME = `d:\apps\apache-ant-1.6.0'
> OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
> TEMP = `/cygdrive/c/DOKUME~1/ADMINI~1/LOKALE~1/Temp'
> COMMONPROGRAMFILES = `C:\Programme\Gemeinsame Dateien'
> IBMLDAP_ALTHOME = `C:\Programme\Rational\common\codeset'
> RATL_RTHOME = `C:\Programme\Rational\Rational Test'
> USERNAME = `Administrator'
> NUTSUFFIX = `1'
> PROCESSOR_LEVEL = `6'
> SYSTEMDRIVE = `C:'
> JAVA_HOME = `C:\Programme\Java\j2re1.4.2_01'
> USERPROFILE = `C:\Dokumente und Einstellungen\Administrator'
> PS1 = `\[\033]0;\w\007
> [EMAIL PROTECTED] \[\033[33m\w\033[0m\]
> $ '
> LOGONSERVER = `\\PC-ARMN'
> PROCESSOR_ARCHITECTURE = `x86'
> !C: = `C:\Dokumente und Einstellungen\Administrator\Desktop'
> SHLVL = `1'
> RWPHOME = `C:\Programme\Rational\common\rwp'
> PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl'
> ITEXT_HOME = `d:\apps\iText'
> HOMEDRIVE = `C:'
> !D: = `D:\Apps\Cygwin\bin'
> NUT_SUFFIXED_SEARCHING = `1'
> PROMPT = `$P$G'
> COMSPEC = `C:\WINNT\system32\cmd.exe'
> TMP = `/cygdrive/c/DOKUME~1/ADMINI~1/LOKALE~1/Temp'
> SYSTEMROOT = `C:\WINNT'
> PROCESSOR_REVISION = `0703'
> CLASSPATH =
>
`;C:\Programme\Java\j2re1.4.2_01\jaxp.jar;D:\Apps\NetBeans\j2sdk1.4.2\jre\lib;d:\apps\iText\iText.jar;d:\apps\iText\itext-xml-1.02.jar;'
> PROGRAMFILES = `C:\Programme'
> NUMBER_OF_PROCESSORS = `1'
> COMPUTERNAME = `PC-ARMN'
> _ = `/usr/bin/cygcheck'
> POSIXLY_CORRECT = `1'
> 
> HKEY_CURRENT_USER\Software\Cygnus Solutions
> HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
> HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
> HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
> HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
> HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
> HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
>   (default) = `/cygdrive'
>   cygdrive flags = 0x0022
> HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
>   (default) = `D:\Apps\Cygwin'
>   flags = 0x000a
> HKEY_LOCAL_MACHINE\SOFTWARE\C

Re: Resizing images from CLI

[Reid Thompson]

zzapper wrote:

From the talk NG I got this info for CLI image manipulation

requires ImageMagick installed and in path

# from imageMagick

convert -sample 80x40 abbeyparkarch.gif s_abbeyparkarch.gif
lsimg abbeyparkarch.gif s_abbeyparkarch.gif

What I'd like now is to resize an image but preserve it's aspect ratio

how do?

  

see the imageMagick homepage
read the convert man page

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated: (experimental) OpenSSH-4.3p2-4

[Corinna Vinschen]

I've just uploaded an experimental version of OpenSSH, 4.3p2-4.

This version uses socketpairs instead of pipes for local connections to
susequent applications, to circumvent (NOT solve) the problems with
pipes hanging in some situations, as for instance discussed in the
thread starting at http://cygwin.com/ml/cygwin/2006-04/msg00767.html


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.  Look for
"openssh" in the 'Net' category.  Because this is an experimental
version, you will have to use the 'Exp' radio button to access this
release of OpenSSH.


  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Resizing images from CLI

[zzapper]

Reid Thompson <[EMAIL PROTECTED]> wrote in news:445206FF.80109
@ateb.com:

> zzapper wrote:
>> From the talk NG I got this info for CLI image manipulation
>>
>> requires ImageMagick installed and in path
>>
>> # from imageMagick
>>
>> convert -sample 80x40 abbeyparkarch.gif s_abbeyparkarch.gif
>> lsimg abbeyparkarch.gif s_abbeyparkarch.gif
>>
>> What I'd like now is to resize an image but preserve it's aspect ratio
>>
>> how do?
>>
>>   
> see the imageMagick homepage
> read the convert man page
> 
http://www.imagemagick.org/script/convert.php

In fact 
convert -sample 80x40 abbeyparkarch.gif s_abbeyparkarch.gif
automatically respects ratio, so only the y dimension is guaranteed

convert -resize 80  abbeyparkarch.gif s_abbeyparkarch.gif
respects ratio width 80

convert -resize x40  abbeyparkarch.gif s_abbeyparkarch.gif
respects ratio height 40



-- 
http://successtheory.com/tips/ Vim, Zsh, MySQL Tips


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated: opengl-1.1.0-8

[André Bleau]

I've uploaded  new version of the OpenGL package, version 1.1.0-8.

Excerpts from README.txt:
__

What has changed since opengl-1.1.0-7

This package was released to avoid conflicts with the new X11R7.0 packages,
including FreeGlut. See 
http://cygwin.com/ml/cygwin-apps/2006-04/msg00079.html for details.


glui-examples were moved from /usr/bin tio /usr/lib

glut.h was moved from /usr/include/GL to /usr/include/w32api/GL

glui.h and gluix.h were moved from /usr/include to /usr/include/w32api

libglui.a and libgluix.a were moved from /usr/lib to /usr/lib/w32api
__

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.  Look for
"opengl" in the 'Graphics' or 'Libs' categories.


If you have general questions or comments, please send them to the
Cygwin mailing list at: "cygwin at cygwin dot com".  I would appreciate
it if you would use this mailing list rather than emailing me directly.

 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

- André Bleau, Cygwin's OpenGL package maintainer.
Please address all questions and problem reports about Cygwin's OpenGL 
package to cygwin at cygwin dot com.


_
Balayez vos courriels entrants et sortants et les pièces jointes et 
contribuez à éliminer les virus destructeurs susceptibles d’y être intégrés. 
http://join.msn.com/?pgmarket=fr-ca&page=features/virus Commencez dès 
maintenant à profiter de tous les avantages de MSN Premium et obtenez les 
deux premiers mois GRATUITS*.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Geomview & Cygwin setup

[Lloyd Wood]

__CYGWIN__ is still valid under gcc version 3.4.4 (cygming special), 
as this test shows:


#include 

int main(void) {

printf("hello. Testing defines.\n");

#if defined(__CYGWIN__)
printf("__CYGWIN__");
#endif

#if defined(__CYGMING__)
printf("__CYGMING__");
#endif

}

[EMAIL PROTECTED] /home/lloyd
$ gcc -o cygtest cygwin.c

[EMAIL PROTECTED] /home/lloyd
$ ./cygtest
hello. Testing defines.
__CYGWIN__

(Why #define says __CYGWIN__ and gcc -v says something else is 
silly.) I suspect something has changed affecting the CYGWIN test in glob.c


L.

At Friday 2006-04-28 12:29 +0100, Lloyd Wood wrote:

(adding in the geomview and cygwin lists.)

Chris,

Looking at the changes in:
http://cvs.sourceforge.net/viewcvs.py/geomview/geomview/src/bin/animate/glob.c
there are specific fixes for Cygwin portability that have been 
included in Geomview 1.8.2 alpha that affect d_ino use; try changing 
the sense of !defined(__CYGWIN__)  to just defined(__CYGWIN__)  and 
see if that works with your compiler. I imagine it will.


I see the output of gcc -v has changed in current cygwin:
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)

It used to be just e.g.:
gcc version 3.3.3 (cygwin special)

cygming, not cygwin? ('ming' is a strong insult in the UK. I get the 
impression the writer doesn't like cygwin.) No idea what pre-release 
gdc or dmd are, or where they've come from, or why I should care about them.


It's awfully tempting to conclude that the compiler is screwing you 
around (because the compiler's authors have been screwing it around, 
because they hate Cygwin?), and you might want to to try an earlier 
version of that. I also wonder if __CYGWIN__ is being defined and 
picked up in the compiler environment correctly.


I'm actually running Geomview 1.8.1 and Geomview 1.8.2-alpha on top 
of cygwin base 1.5.19-4... but I compiled them on a much earlier 
cygwin with an earlier version of gcc, and on an entirely different 
machine that I recently migrated the files from. (I haven't tried 
recompiling, and your note suggests I would be unwise to.)


But I have compiled SaVi and Geomview on an earlier Cygwin;
http://cvs.sourceforge.net/viewcvs.py/savi/savi-dev/README?rev=1.36&view=markup
tells me the first base Cygwin I used successfully was 1.5.9-1, and 
also lists the successful versions of gcc.


cheers,

L.

> Hi Lloyd,
>
> I'm a masters student at UBC in Vancouver and I'm trying to get Geomview
> installed on my Windows machine. I'm following the instructions that
> you've posted via geomview.org but my 
compilation is running into an

> error. It seems in glob.c (in directory
> geomview-1.8.2-alpha/src/bin/animate) there is a reference to d_ino of
> the dirent structure. Now from my research into fixing this it seems
> that d_ino is not supported in version 1.5.19-4 but will be in 1.5.20, I
> also tried with version 1.5.8-1 with the same result. Do you know of any
> way I can get around this problem? I hope this is description is
> satisfactory, if you need any clarification please let me know.

Cheers,
Chris Elliott

<[EMAIL PROTECTED]>


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Lloyd Wood]

At Friday 2006-04-28 12:46 +0100, Dave Korn wrote:
> > cygming, not cygwin? ('ming' is a strong insult in the UK.
>
>  Yes, and we also do tongue-in-cheek humour quite well.  Well, at least some
> of us do.

humour is intended to generate an emotional response - laughter.

>> I get the impression the writer doesn't like cygwin.)
>
>  Who precisely do you suppose "the writer" would have been?

More accurately, someone who doesn't like Windows.


 Now go away and find out what MinGW is and why cygwin's compiler
might want to refer to it.


A referral to it and bad pun would be CygMinGW, which would at least 
include the full MinGW 'clue'. Before mailing I attempted some 
searches on 'ming' with 'gcc' and, unsurprisingly, got nowhere.


Clearer, and backwardly compatible, would be a gcc version report of 
something like:

gcc version 3.4.4 (cygwin special) (MinGW, gdc 0.12, using dmd 0.125)

which has the advantages of being unambiguous and providing 
searchable clues for context.



 Once you stop placing a superfluous emotional
colouring on the word you will be less distracted by irrelevancies and more
able to solve your bug rationally.  Stop spreading misinformed FUD.


The attempted pun to generate humour is itself (surprise) 'a 
superfluous emotional colouring on the word', and is the distraction 
leading me to irrelevancies. That superfluous attempt at humour has 
certainly generated an emotional response.


Saying 'ming' instead of 'MinGW' is a deliberately misleading 
distraction. I was deliberately misinformed by gcc -v.


__CYGWIN__ is defined for gcc; gcc -v should report 'cygwin special'. 
I do not recommend changing the environment to __CYGMING__ to match 
in a further attempt at humour.


If you want people to use the information you provide rationally, do 
not colour that information with irrational attempts at humour to 
provide misinformation that causes doubt.


We need to trust the output of gcc -v.

L.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Dave Korn]

On 28 April 2006 14:35, Lloyd Wood wrote:

> __CYGWIN__ is still valid under gcc version 3.4.4 (cygming special),
> as this test shows:

  You really need to read some manuals, as you wouldn't have to do things like
this if you had read about the -dM option.  (You also wouldn't have led
yourself up the garden path about mingw if you had read about -mno-cygwin).
Hint:

 gcc -dM -E - < /dev/null

> (Why #define says __CYGWIN__ and gcc -v says something else is
> silly.) 

  No it isn't.  Your assumption that the two have to be in some way related is
silly.  As is attempting to parse the output from "gcc -v" to detect a given
target rather than using one of the predefined macros, which is what they are
for and how it is supposed to be done.  The output from "gcc -v" is for
*humans* to read, and version strings are allowed to have free-format text and
no guarantees are provided regarding the content or formatting of that text or
how it may or may not change in the future.

>I suspect something has changed affecting the CYGWIN test in glob.c

  First you said that __CYGWIN__ is still valid.  Then you think that
something has changed affecting the '#ifdef __CYGWIN__' test in glob.c.  Since
you acknowledge that __CYGWIN__ is still valid, presumably you believe that
#ifdef has been changed to only succeed if a symbol is not defined?

  Now, if you stop posting random guesses and uninformed speculation and try
and tell us what the actual *problem* is, perhaps we can answer some questions
for you about the recent changes to d_ino under cygwin?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Dave Korn]

On 28 April 2006 15:04, Lloyd Wood wrote:

[most of what I want to say is in the response I just sent before I just
received this reply, so I'm only going to reiterate one single *very*
important point].

> Clearer, and backwardly compatible, would be a gcc version report of
> something like:
> gcc version 3.4.4 (cygwin special) (MinGW, gdc 0.12, using dmd 0.125)

> Saying 'ming' instead of 'MinGW' is a deliberately misleading
> distraction.

  No, it's a linguistic constuct called a "contraction".  You saw "cyg"
without the "win" and didn't complain about that.

>  I was deliberately misinformed by gcc -v.

  No, you misinformed yourself by your false assumptions about the nature of
gcc -v.

> __CYGWIN__ is defined for gcc; gcc -v should report 'cygwin special'.
> I do not recommend changing the environment to __CYGMING__ to match
> in a further attempt at humour.
> 
> If you want people to use the information you provide rationally, do
> not colour that information with irrational attempts at humour to
> provide misinformation that causes doubt.
> 
> We need to trust the output of gcc -v.

  No, this is completely wrong and absolutely not what you want to do.  The
output of "gcc -v" is a human-readable summary of various internal information
which can be obtained by more reliable means for programmatic use.  Your
attempt to indirectly deduce the same info from a freeform text string
presupposes many assumptions that simply do not hold, and therefore is doomed
to incorrectness.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Lloyd Wood]

At Friday 2006-04-28 15:17 +0100, Dave Korn wrote:

> If you want people to use the information you provide rationally, do
> not colour that information with irrational attempts at humour to
> provide misinformation that causes doubt.
>
> We need to trust the output of gcc -v.

  No, this is completely wrong and absolutely not what you want to do.  The
output of "gcc -v" is a human-readable summary of various internal information
which can be obtained by more reliable means for programmatic use.


So you admit that gcc -v's output is deliberately unreliable and will 
lie to the human reader, then.


L. 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Lloyd Wood]

At Friday 2006-04-28 15:11 +0100, Dave Korn wrote:

perhaps we can answer some questions
for you about the recent changes to d_ino under cygwin?


So, something has changed after all?

Perhaps you could just point me at a document detailing those changes 
to d_ino that you mention?


L.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Dave Korn]

On 28 April 2006 15:42, Lloyd Wood wrote:

> At Friday 2006-04-28 15:17 +0100, Dave Korn wrote:
>>> If you want people to use the information you provide rationally, do
>>> not colour that information with irrational attempts at humour to
>>> provide misinformation that causes doubt.
>>> 
>>> We need to trust the output of gcc -v.
>> 
>>   No, this is completely wrong and absolutely not what you want to do.  The
>> output of "gcc -v" is a human-readable summary of various internal
>> information which can be obtained by more reliable means for programmatic
>> use. 
> 
> So you admit that gcc -v's output is deliberately unreliable and will
> lie to the human reader, then.

  What are you gibbering about?

  "Unreliable"?  It's the exact verbatim same every single time you run it.
That seems 100% reliable to me.  Of course, it's pretty unreliable if you try
to use it for purposes it is not intended for, like matching different
versions of gcc that target the same arch, because there can be more than one
version of gcc for any given target and they will have different version
strings.  It's also unreliable if you try and use it to make the tea or
predict the weather.  All three of these uses are not what it was intended for
and hence your fault, not the compiler's or anyone else's.

  And "lie"?  Now you're attributing intentionality to an inanimate object.

  Give it up.  It's only *you* who believes that the output of gcc -v is meant
to be some kind of identification mechanism.  AND YOU ARE WRONG.

  Sure, there's enough information there for an intelligent human being to
extract the regularities and notice the differences, but it's a false
inference that those regularities are systematic, or that a simple
pattern-matching test can suffice to replace the kind of intellectual skills
that a human being brings to bear on the problem.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync over ssh hang issue understood

[Steven Hartland]

Corinna Vinschen wrote:

It works fine for me with the latest snapshot.  I tried Peter's
example with 1000 files and rsync over ssh works like a charm for me.
Sigh. 


This is really a tricky problem.  What I could do to circumvent this
at least for connections over ssh is to upload an OpenSSH test version
which uses socketpairs instead of pipes for the local connection to
the applications.  This avoids using pipes which are the culprit here,
apparently.I would mark it as experimental version, but actually
the only difference would be that it would be a few per cent slower
than the version using pipes.  And that it probably doesn't hang.

Is there interest in such a version?


Good news this does fix the issue. I've just successfully done
an rsync of ~1G ( 1700 files ) with no problem at all.

Also note that due to the existing performance issues in ssh ( I've
still not had chance to dig more about that sorry ) there is NO
noticable slowdown when comparing this version to the baseline
version of openssh.

All in all this version is a massive improvement which is fantastic
news!!!

Many thanks Corinna.

   Steve



This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone (023) 8024 3137
or return the E.mail to [EMAIL PROTECTED]


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Lloyd Wood]

At Friday 2006-04-28 15:17 +0100, Dave Korn wrote:

> __CYGWIN__ is defined for gcc; gcc -v should report 'cygwin special'.
> I do not recommend changing the environment to __CYGMING__ to match
> in a further attempt at humour.
>
> If you want people to use the information you provide rationally, do
> not colour that information with irrational attempts at humour to
> provide misinformation that causes doubt.
>
> We need to trust the output of gcc -v.

  No, this is completely wrong and absolutely not what you want to do.  The
output of "gcc -v" is a human-readable summary of various internal information
which can be obtained by more reliable means for programmatic use.  Your
attempt to indirectly deduce the same info from a freeform text string
presupposes many assumptions that simply do not hold, and therefore is doomed
to incorrectness.


In that case, gcc -v may as well return an empty string, since, as 
you say, it's always going to be wrong, and because obviously even 
humans have trouble parsing its output.


L.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Call for testing Cygwin snapshot

[Christopher Faylor]

On Fri, Apr 28, 2006 at 10:22:58AM +0200, Danilo Turina wrote:
>Christopher Faylor wrote:
>>On Thu, Apr 27, 2006 at 03:38:27PM +0200, Danilo Turina wrote:
>>>No, sorry: I'm not using a snapshot. I thought you intended to say that 
>>>/bin/pwd would have failed also with the current version.
>>
>>Then please choose another thread to discuss any issues not involved with
>>the Cygwin snapshot.
>
>No, there's no issue at all in the stable versione, only a little 
>misunderstading: I (wrongly) understood (from a previous message) that a 
>problem present in the stable version was also present in the snapshot.
>
>Verifying that the stable version (of my Cygwin installation) was immune 
>to that problem I notified this information in the aim of helping the 
>debugging of the snapshot.

Nevertheless, we really are only interested in discussing the snapshot in
this thread.  If you or anyone haven't even *tried* it, then there is no
reason to chime in here.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Dave Korn]

On 28 April 2006 15:45, Lloyd Wood wrote:

> At Friday 2006-04-28 15:11 +0100, Dave Korn wrote:
>> perhaps we can answer some questions
>> for you about the recent changes to d_ino under cygwin?
> 
> So, something has changed after all?

  If you don't read *carefully* and with attention to detail, you're not going
to get anywhere.  Your question is a straw man: nobody has claimed that
nothing has changed anywhere in the universe.  Please try and remember YOUR
OWN words:

>I suspect something has changed affecting the CYGWIN test in glob.c

  I pointed out that nothing has changed affecting the cygwin test in glob.c;
it is a total invention on your part to suppose that is the same as claiming
nothing else has changed elsewhere.  Don't go attempting to put words in my
mouth because it won't wash.

> Perhaps you could just point me at a document detailing those changes
> to d_ino that you mention?

  No, because no such document exists.  It has been discussed at great length
over the past couple of months on the cygwin mailing list.  You are at a
university and presumably are familiar with the concept of "research", and
"googling for information", aren't you?  


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How do I detect a failure in Make?

[mwoehlke]

Richard Quadling wrote:

On 26/04/06, mwoehlke <[EMAIL PROTECTED]> wrote:

Richard Quadling wrote:

I have the following bash script ...

#!/bin/sh
cvs up 2> $HOME/cvs1.log > $HOME/cvs2.log
cd phpdoc
autoconf -v -d --warnings=all &> $HOME/autoconf.log
./configure --with-source=./../php-src --with-pear-source=./../pear
--with-chm=yes --with-treesaving > $HOME/configure.log
make test > $HOME/make_test.log
make test_xml > $HOME/make_test_xml.log
make chm_xsl > $HOME/make_chm_xsl.log

Is there a way of stopping the makes if there was a problem.



Matthew said using [ $? -eq 0 ] || exit $? after each make line would work.


It doesn't. The issue is that the make function is crashing (the core
dump ??!!!??).


http://cygwin.com/acronyms/#IWFM. A process that dumps core results in a 
non-zero exit status (not that 'make' should ever core dump). Did you 
try some of the alternatives? Are you sure you haven't clobbered your 
exit code?


If you can run 'make' at the command line in such a way that it fails, 
does ' || echo fail' work?


--
Matthew
"Sorry. Wrong species." --ST-TNG


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync over ssh hang issue understood

[Christopher Faylor]

On Fri, Apr 28, 2006 at 06:25:35AM -0400, Brett Serkez wrote:
>I've noticed multiple postings indicating issues with pipes.  Wouldn't
>it be better to track this down, it would likely fix multiple
>problems.

I think you meant to post this to the cygwin-facile-advice mailing list.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Lloyd Wood]

At Friday 2006-04-28 16:01 +0100, Dave Korn wrote:

On 28 April 2006 15:45, Lloyd Wood wrote:

> At Friday 2006-04-28 15:11 +0100, Dave Korn wrote:
>> perhaps we can answer some questions
>> for you about the recent changes to d_ino under cygwin?
>
> So, something has changed after all?

  If you don't read *carefully* and with attention to detail, 
you're not going

to get anywhere.  Your question is a straw man: nobody has claimed that
nothing has changed anywhere in the universe.

[..]

> Perhaps you could just point me at a document detailing those changes
> to d_ino that you mention?

  No, because no such document exists.  It has been discussed at great length
over the past couple of months on the cygwin mailing list.


Thankyou for that hint. From that we have established: yes, something 
has changed in d_ino; yes, documents exist.


(Get over yourself.)

L.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

where to find "dig" command?

[Hiroki Sakagami]

Where is "dig" DNS lookup command?
It seems that search at http://cygwin.com/packages/ has no result package.

--
Hiroki Sakagami

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Geomview & Cygwin setup

[Christopher Faylor]

On Fri, Apr 28, 2006 at 12:29:52PM +0100, Lloyd Wood wrote:
>It's awfully tempting to conclude that the compiler is screwing you 
>around (because the compiler's authors have been screwing it around, 
>because they hate Cygwin?), and you might want to to try an earlier 
>version of that. I also wonder if __CYGWIN__ is being defined and 
>picked up in the compiler environment correctly.

As the person who started using the term "cygming" in the gcc context, I
want to assure you that the software was not intended to maliciously
cause people problems.  I understand that this happens quite often in
the free software world -- people spend hours cackling with glee as they
produce a binary package whose sole intent is to provide the illusion of
usefulness, when it will really just format a hard drive or something.

However, although I did not actually produce the package in question, I
can vouch for the person who did.  So please set aside your fears and
concerns about gcc.  The word "ming" in this context merely reflects an
unforgivable lack of knowledge of British slang.

I should point out that it is unlikely that anyone is going to be changing
gcc to accommodate the needs of Geomview (whatever that is) so perhaps
you should mark Geomview as "unsupported on cygwin" since this version
number difference is apparently close to an insurmountable problem.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: where to find "dig" command?

[mwoehlke]

Hiroki Sakagami wrote:

Where is "dig" DNS lookup command?
It seems that search at http://cygwin.com/packages/ has no result package.


http://www.isc.org/index.pl?/sw/bind/ - but I can't tell what you need 
to download; good luck!


--
Matthew
"Sorry. Wrong species." --ST-TNG


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Geomview & Cygwin setup

[Christopher Faylor]

On Fri, Apr 28, 2006 at 04:17:14PM +0100, Lloyd Wood wrote:
>At Friday 2006-04-28 16:01 +0100, Dave Korn wrote:
>>On 28 April 2006 15:45, Lloyd Wood wrote:
>>
>>> At Friday 2006-04-28 15:11 +0100, Dave Korn wrote:
 perhaps we can answer some questions
 for you about the recent changes to d_ino under cygwin?
>>>
>>> So, something has changed after all?
>>
>>  If you don't read *carefully* and with attention to detail, 
>>you're not going
>>to get anywhere.  Your question is a straw man: nobody has claimed that
>>nothing has changed anywhere in the universe.
>[..]
>>> Perhaps you could just point me at a document detailing those changes
>>> to d_ino that you mention?
>>
>>  No, because no such document exists.  It has been discussed at great 
>>  length
>>over the past couple of months on the cygwin mailing list.
>
>Thankyou for that hint. From that we have established: yes, something 
>has changed in d_ino; yes, documents exist.
>
>(Get over yourself.)

Oh Chinese Dynasty you.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Dave Korn]

On 28 April 2006 16:17, Lloyd Wood wrote:


> (Get over yourself.)

  You are the one who believes that reality should be changed to match your
false assumptions about the intent of "gcc -v".  You are also the one who has
publicly accused Gerrit et al of committing an act of massive
unprofessionalism and abusing their responsibilities as maintainers.

  Hence I suggest you take a big spoonful of your own medicine.

[  This space intentionally left blank for L.Wood to explain once more why he
is right and everyone else in the world is wrong.  ]

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Williams, Gerald S \(Jerry\)]

If you need to find out what gcc is targeting, perhaps you should
use "-dumpmachine" instead.

 $ gcc -dumpmachine
 i686-pc-cygwin
 $ gcc -dumpmachine -mno-cygwin
 i686-pc-mingw32

Lloyd Wood wrote:
> cygming, not cygwin? ('ming' is a strong insult in the UK. I get
> the impression the writer doesn't like cygwin.)

You think that's bad? When the company I was working for spun off
from AT&T, they decided to name themselves "loo scent". :-) I must
admit I'd never heard of the UK "ming" until you mentioned it. I
suspect we at least pronounce it differently, though.

gsw

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Resizing images from CLI

[zzapper]

zzapper <[EMAIL PROTECTED]> wrote in news:Xns97B38CA43A097zzappergmailcom@
80.91.229.5:

> Reid Thompson <[EMAIL PROTECTED]> wrote in news:445206FF.80109
> @ateb.com:
> 
>> zzapper wrote:
> http://www.imagemagick.org/script/convert.php
> 
> In fact 
> convert -sample 80x40 abbeyparkarch.gif s_abbeyparkarch.gif
> automatically respects ratio, so only the y dimension is guaranteed
> 
> convert -resize 80  abbeyparkarch.gif s_abbeyparkarch.gif
> respects ratio width 80
> 
> convert -resize x40  abbeyparkarch.gif s_abbeyparkarch.gif
> respects ratio height 40
> 
> 
BTW  lsimg.exe is actually my own renaming of :-
> identify abbeyparkarch.gif


-- 
http://successtheory.com/tips/ Vim, Zsh, MySQL Tips


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Lloyd Wood]

At Friday 2006-04-28 11:45 -0400, Williams, Gerald S \(Jerry\) wrote:

If you need to find out what gcc is targeting, perhaps you should
use "-dumpmachine" instead.

 $ gcc -dumpmachine
 i686-pc-cygwin
 $ gcc -dumpmachine -mno-cygwin
 i686-pc-mingw32


Having identification behaviour dependent on a cygwin-specific flag 
like this is.. insane. Doing the former (which is what you'd expect) 
makes you none the wiser about mingw. The latter is a special case 
where you already have some idea what the target may be, so why would 
you issue the command? Begs the question.




Lloyd Wood wrote:
> cygming, not cygwin? ('ming' is a strong insult in the UK. I get
> the impression the writer doesn't like cygwin.)

You think that's bad? When the company I was working for spun off
from AT&T, they decided to name themselves "loo scent". :-)


Ah, the famous brown ring of quality, which, alas, won't exist for much longer.

cheers,

L.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Dave Korn]

On 28 April 2006 17:07, Lloyd Wood wrote:

> At Friday 2006-04-28 11:45 -0400, Williams, Gerald S \(Jerry\) wrote:
>> If you need to find out what gcc is targeting, perhaps you should use
>> "-dumpmachine" instead. 
>> 
>>  $ gcc -dumpmachine
>>  i686-pc-cygwin
>>  $ gcc -dumpmachine -mno-cygwin
>>  i686-pc-mingw32
> 
> Having identification behaviour dependent on a cygwin-specific flag
> like this is.. insane. 

  When you use -mno-cygwin, you are invoking A DIFFERENT compiler.  Having the
*same* identification for two different compilers that target different
targets would be insane.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Lloyd Wood]

At Friday 2006-04-28 17:44 +0100, Dave Korn wrote:

On 28 April 2006 17:07, Lloyd Wood wrote:

> At Friday 2006-04-28 11:45 -0400, Williams, Gerald S \(Jerry\) wrote:
>> If you need to find out what gcc is targeting, perhaps you should use
>> "-dumpmachine" instead.
>>
>>  $ gcc -dumpmachine
>>  i686-pc-cygwin
>>  $ gcc -dumpmachine -mno-cygwin
>>  i686-pc-mingw32
>
> Having identification behaviour dependent on a cygwin-specific flag
> like this is.. insane.

  When you use -mno-cygwin, you are invoking A DIFFERENT 
compiler.  Having the

*same* identification for two different compilers that target different
targets would be insane.


But gee, that's exactly what gcc -v provides. A single identification 
for both compilers.


Why isn't there a gcc -v -mno-cygwin, then?

It's all positively minging. (Chris: note the usage tip. First g 
pronounced as j, so it's unlike any Chinese dynasties or Flash 
Gordon's nemesis.)


L.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Dave Korn]

On 28 April 2006 18:04, Lloyd Wood wrote:

> At Friday 2006-04-28 17:44 +0100, Dave Korn wrote:
>> On 28 April 2006 17:07, Lloyd Wood wrote:
>> 
>>> At Friday 2006-04-28 11:45 -0400, Williams, Gerald S \(Jerry\) wrote:
 If you need to find out what gcc is targeting, perhaps you should use
 "-dumpmachine" instead. 
 
  $ gcc -dumpmachine
  i686-pc-cygwin
  $ gcc -dumpmachine -mno-cygwin
  i686-pc-mingw32
>>> 
>>> Having identification behaviour dependent on a cygwin-specific flag
>>> like this is.. insane.
>> 
>>   When you use -mno-cygwin, you are invoking A DIFFERENT
>> compiler.  Having the
>> *same* identification for two different compilers that target different
>> targets would be insane.
> 
> But gee, that's exactly what gcc -v provides. A single identification
> for both compilers.

How many times, for crying out loud?  The output of "gcc
-v" IS NOT A FORMAL IDENTIFIER OF ANY SORT WHATSOEVER.

 > Why isn't there a gcc -v -mno-cygwin, then?

  Because it's still the same compiler package?  Because nobody has ever cared
about it because nobody has ever been daft enough to attempt to misuse the
"gcc -v" output in this way before?

  [  This space intentionally left blank for L.Wood to explain why "gcc -v"
ought to be a formal identifier and why everyone else in the world should
change things round so we can do it all his way.  ]

> It's all positively minging. (Chris: note the usage tip. First g
> pronounced as j, so it's unlike any Chinese dynasties or Flash
> Gordon's nemesis.)

  Actually it's minging to rhyme with singing, as anyone who has watched
Little Britain or Catherine Tate's show should know.

  [  This space intentionally left blank for L.Wood to insist that everyone
should pronounce words the way that /he/ does.  ]

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Lloyd Wood]

At Friday 2006-04-28 18:16 +0100, Dave Korn wrote:

On 28 April 2006 18:04, Lloyd Wood wrote:

> At Friday 2006-04-28 17:44 +0100, Dave Korn wrote:
>> On 28 April 2006 17:07, Lloyd Wood wrote:
>>
>>> At Friday 2006-04-28 11:45 -0400, Williams, Gerald S \(Jerry\) wrote:
 If you need to find out what gcc is targeting, perhaps you should use
 "-dumpmachine" instead.

  $ gcc -dumpmachine
  i686-pc-cygwin
  $ gcc -dumpmachine -mno-cygwin
  i686-pc-mingw32
>>>
>>> Having identification behaviour dependent on a cygwin-specific flag
>>> like this is.. insane.
>>
>>   When you use -mno-cygwin, you are invoking A DIFFERENT
>> compiler.  Having the
>> *same* identification for two different compilers that target different
>> targets would be insane.
>
> But gee, that's exactly what gcc -v provides. A single identification
> for both compilers.

How many times, for crying out loud?  The output of "gcc
-v" IS NOT A FORMAL IDENTIFIER OF ANY SORT WHATSOEVER.

 > Why isn't there a gcc -v -mno-cygwin, then?

  Because it's still the same compiler package?  Because nobody has 
ever cared

about it because nobody has ever been daft enough to attempt to misuse the
"gcc -v" output in this way before?


What, reading  gcc -v's output using eyes and a screen is misuse?



> It's all positively minging. (Chris: note the usage tip. First g
> pronounced as j, so it's unlike any Chinese dynasties or Flash
> Gordon's nemesis.)

  Actually it's minging to rhyme with singing, as anyone who has watched
Little Britain or Catherine Tate's show should know.


Ah, that would be the BBC's "received pronunciation" take on the term.

L.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

ssh from remote system into cygwin bash, JScript engine won't run

[David Wuertele]

I have an IDE ("VDSP++") from a vendor on which I'm trying to automate
software builds.  It is a windows-only application, and they require
that I write scripts for the IDE in JScript.

When I use the windows host's console display to run a cygwin bash
shell, I can execute my automated build just fine:

   /path/to/vendors/Idde.exe -f /path/to/my/script.js

But when I use ssh to remotely login to the windows host, also on a
bash shell, and try to execute the automated build, it complains that
the JScript engine can't be loaded.  

I verified
1) my environment variables are set identically in both the local case
   and the remote login case
2) in the service control panel, the sshd's login properties tab has
   "allow interaction with display" enabled

My vendor tells me that something in cygwin's sshd is probably
preventing the windows JScript DLL from loading properly.  Does anyone
here have experience running an appliaction over sshd that uses
JScript?

Thanks,
Dave


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Geomview & Cygwin setup

[Larry Hall (Cygwin)]

Lloyd Wood wrote:

At Friday 2006-04-28 18:16 +0100, Dave Korn wrote:

On 28 April 2006 18:04, Lloyd Wood wrote:

> At Friday 2006-04-28 17:44 +0100, Dave Korn wrote:
>> On 28 April 2006 17:07, Lloyd Wood wrote:
>>
>>> At Friday 2006-04-28 11:45 -0400, Williams, Gerald S \(Jerry\) wrote:
 If you need to find out what gcc is targeting, perhaps you should 
use

 "-dumpmachine" instead.

  $ gcc -dumpmachine
  i686-pc-cygwin
  $ gcc -dumpmachine -mno-cygwin
  i686-pc-mingw32
>>>
>>> Having identification behaviour dependent on a cygwin-specific flag
>>> like this is.. insane.
>>
>>   When you use -mno-cygwin, you are invoking A DIFFERENT
>> compiler.  Having the
>> *same* identification for two different compilers that target 
different

>> targets would be insane.
>
> But gee, that's exactly what gcc -v provides. A single identification
> for both compilers.

How many times, for crying out loud?  The output 
of "gcc

-v" IS NOT A FORMAL IDENTIFIER OF ANY SORT WHATSOEVER.

 > Why isn't there a gcc -v -mno-cygwin, then?

  Because it's still the same compiler package?  Because nobody has 
ever cared
about it because nobody has ever been daft enough to attempt to misuse 
the

"gcc -v" output in this way before?


What, reading  gcc -v's output using eyes and a screen is misuse?



> It's all positively minging. (Chris: note the usage tip. First g
> pronounced as j, so it's unlike any Chinese dynasties or Flash
> Gordon's nemesis.)

  Actually it's minging to rhyme with singing, as anyone who has watched
Little Britain or Catherine Tate's show should know.


Ah, that would be the BBC's "received pronunciation" take on the term.


Isn't this thread getting a bit off-topic?  Llyod, if you feel there is a
problem here that needs a resolution, may I suggest that you submit a
patch?  At least then the discussion could turn from visual and linguistic
aspects of gcc back to technical.

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [patch] fix spurious SIGSEGV faults under Cygwin

[Brian Dessent]

"Gautero, L. (Luca)" wrote:
> 
> Dear Mr
> 
> After giving chase to a segmentation fault error, on the internet one thread 
> to which you contributed came out:
> 
> http://www.mail-archive.com/cygwin-patches@cygwin.com/msg03531.html
> 

Please keep discussions on the mailing list.  Do not send email directly
to me.

The issue you are referring to has been fixed for quite some time.  The
patches I posted are completely redundant and useless now.  Pretend they
do not exist.

The patch that implments this on the gdb side is
.

The patch that implements the start of the fix on the cygwin side is
.

So, if you run a recent Cygwin snapshot and a build of gdb after
2006-02-20 you will not experience the problem.

> You propose some patches to solve the problem, but from what I understood 
> these are not for end user of cygwin since they act on sources which after a 
> normal installation are no longer there, is there an update to solve this 
> problem?

Sorry, but that is completely bogus logic.  The issue only affects
people using GDB.  End users don't typically use GDB.  If you are
debugging something with GDB then you are probably familiar enough with
source code and how to build patch and build it.  If not, then just wait
for an updated binary of the affected programs to be released.  If you
are talking about a situation where a SEGV fault occurs outside of GDB
then this whole issue is irrelevant, because you are talking about
something unrelated.

> 
> p.s. still related (mailing list)
> http://www.nabble.com/Thread-support-in-cygwin%21-t1442219.html#a3899853

This has absolutely nothing to do with the issue you first mentioned.

> http://www.cygwin.com/ml/cygwin/2005-01/msg00527.html

This too has absolutely nothing to do with the above issue.

> The program that gives out this error uses fltk, and on the forum of the site 
> someone quote a possible solution in changing the POSIX thread of
> WIN32 from internal to a code available online, unfortunately this is not 
> possible under cygwin, either way probably the error would have stayed
> there...
> http://www.fltk.org/newsgroups.php?s1+gfltk.bugs+v1+T0+Qpthread

This is talking about detecting the thread library during "configure"
execution.  Again, this has absolutely nothing to do with anything you
have mentioned previously in this email, especially not the GDB issue. 
If you are building a native WIN32 application (i.e. non-Cygwin) then
using -lpthread is probably wrong.  If you are building a Cygwin
application then you must use Cygwin's pthread implmentation and you
don't need any kind of -lpthread flag at all.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Geomview & Cygwin setup

[Lloyd Wood]

At Friday 2006-04-28 17:44 +0100, you wrote:

On 28 April 2006 17:07, Lloyd Wood wrote:

> At Friday 2006-04-28 11:45 -0400, Williams, Gerald S \(Jerry\) wrote:
>> If you need to find out what gcc is targeting, perhaps you should use
>> "-dumpmachine" instead.
>>
>>  $ gcc -dumpmachine
>>  i686-pc-cygwin
>>  $ gcc -dumpmachine -mno-cygwin
>>  i686-pc-mingw32
>
> Having identification behaviour dependent on a cygwin-specific flag
> like this is.. insane.

  When you use -mno-cygwin, you are invoking A DIFFERENT compiler.


If you don't install any of the gcc-mingw- upgrade stuff (devel tab 
in Cygwin), you only want ONE compiler.


L.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Geomview & Cygwin setup

[Brian Dessent]

Lloyd Wood wrote:

> If you don't install any of the gcc-mingw- upgrade stuff (devel tab
> in Cygwin), you only want ONE compiler.

It's not possible to install one without the other, at least not without
overriding setup.exe's wishes, because gcc-core includes gcc-mingw-core
on the "requries" line, and similarly for all the other modules.  This
means if you select one the other will be added automatically.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Geomview & Cygwin setup

[Larry Hall (Cygwin)]

Brian Dessent wrote:

Lloyd Wood wrote:


If you don't install any of the gcc-mingw- upgrade stuff (devel tab
in Cygwin), you only want ONE compiler.


It's not possible to install one without the other, at least not without
overriding setup.exe's wishes, because gcc-core includes gcc-mingw-core
on the "requries" line, and similarly for all the other modules.  This
means if you select one the other will be added automatically.


And, implied by Brian's response but is worthwhile to state explicitly,
if you choose to override setup.exe's defaults here, it's assumed that
you know what you're doing (i.e. what the consequences are, etc.)  But
then you're creating a custom installation of Cygwin and such installs
are not supported by this list.  That means you're on your own if you
run into problems.  I don't know if this situation applies to Lloyd's
case or not.  But I thought it prudent to tie up any perceived loophole
here. :-)

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: where to find "dig" command?

[Thorsten Kampe]

* Hiroki Sakagami (2006-04-28 16:19 +)
> Where is "dig" DNS lookup command?
> It seems that search at http://cygwin.com/packages/ has no result package.

ftp://ftp.isc.org/isc/bind/contrib


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Geomview & Cygwin setup

[Christopher Faylor]

On Fri, Apr 28, 2006 at 03:39:14PM -0400, Larry Hall (Cygwin) wrote:
>Brian Dessent wrote:
>>Lloyd Wood wrote:
>>
>>>If you don't install any of the gcc-mingw- upgrade stuff (devel tab
>>>in Cygwin), you only want ONE compiler.
>>
>>It's not possible to install one without the other, at least not without
>>overriding setup.exe's wishes, because gcc-core includes gcc-mingw-core
>>on the "requries" line, and similarly for all the other modules.  This
>>means if you select one the other will be added automatically.
>
>And, implied by Brian's response but is worthwhile to state explicitly,
>if you choose to override setup.exe's defaults here, it's assumed that
>you know what you're doing (i.e. what the consequences are, etc.)  But
>then you're creating a custom installation of Cygwin and such installs
>are not supported by this list.  That means you're on your own if you
>run into problems.  I don't know if this situation applies to Lloyd's
>case or not.  But I thought it prudent to tie up any perceived loophole
>here. :-)

Let me state something else, too.

We're not going to be changing Cygwin's gcc.  I haven't seen anything in
this thread to support the notion that gcc is doing anything wrong.  I
will admit, however, to being biased by the fact that the initial
message in this discussion was rather insulting even if it was arguably
intended to be "humorous".

So, that means that "Geomview" will either have to use what we provide
or decide not to support Cygwin.

Given this statement of fact, further complaints about how things work
or offering of opinions about how things should work would be fruitless.

So, I would appreciate it if this thread would now die or move to
cygwin-talk.  Gerald Williams has already valiantly tried to do this
once.  Let's follow his example.

cygwin-talk AT cygwin PERIOD com

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Windows Vista Beta 2

[Jennifer Smith]

I tried to install cygwin on the Windows Vista Beta 2 (build 5308), here are 
the problems I've run into:

1) During package install bash seems to crash.
I get this dialog from windows:
Please close bash.exe
A problem caused the program to stop working correctly. Windows will notify 
you if a solution is available.


This occurs (it appears) once per package.

2) After install tools crash. About one in three times I run ls in /usr/bin 
I get:


[EMAIL PROTECTED] /usr/bin]$ ls
 6 [main] ? (4596) C:\cygwin\bin\tcsh.exe: *** fatal error - couldn't 
alloc
ate heap, Win32 error 0, base 0x80, top 0x89B000, reserve_size 630784, 
alloc

size 634880, page_const 4096
36534798 [main] tcsh 3908 child_copy: stack write copy failed, 
0x227010..0x23000

0, done 0, windows pid 2256708, Win32 error 5
No more processes.

If you would like anymore information feel free to contact me at this email 
address.


Thanks,

Jennifer

_
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: "Ghost" processes on Cygwin

[mwoehlke]

mwoehlke wrote:
I'm seeing something funny. While trying to build a large program on 
Cygwin using cl.exe (i.e. I am building a non-Cygwin app; just using 
Cygwin to drive 'make'), every now and then, cl.exe hangs. Before you 
tell me I'm on the wrong list :-), here's the funny part. If I do 'ps' 
in Cygwin, I can see the 'cl' process, along with its WINPID. However, 
it doesn't show up in task manager! Also, there are about five processes 
that are clearly Cygwin processes (bash.exe or sh.exe) that do NOT show 
up in Cygwin's 'ps'.


Following up on this... I still haven't determined a cause, but it seems 
to have gone away for the moment. I should note that a: I was building 
on an NFS volume, and b: I had running in another window 'while sleep 2; 
do make install; done' (an equivalent, anyway). After stopping the 
repeating 'make', I'm not seeing it any more.


Maybe this information can help with the 'cron job hangs' problem. 
Anyway, if anyone figures out anything, please share with the rest of us.


--
Matthew
"Sorry. Wrong species." --ST-TNG


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Reproducible hang with unusual border conditions

[Volker Quetschke]

Hi Larry,

Larry Hall (Cygwin) wrote:

On 04/26/2006, Volker Quetschke wrote:


1. It only hangs from rxvt. (Invoked with shortlink from desktop to:
C:\cygwin\bin\rxvt.exe  -cr green -sl 1000 -tn linux -e /usr/bin/bash 
--login -i)
I guess the actual switches don't matter. Startting the following 
example from
the bash that is started from the cygwin icon (cygwin.bat) didn't show 
the problem
so far. 


Will it reproduce from bash in a command prompt if you set 'tty' in your
CYGWIN environment variable first?


I tried that already yesterday but didn't report back. No, even after
several hours running in a bash from from a comand prompt with CYGWIN=tty
set before starting bash I cannot reproduce that starnge hang.

  Volker

P.S.: I'm actually not very interested in this 4nt hang, but I wonder if the
original problem is also related to the pipe problem
  
but I don't know if redirecting output with dup() also triggers
the pipe problem. That is at least where the hang in the OOo build seems
to occur. A process started posix_spawnp() or execvp() with it's output
redirected seems to hang sometimes.

P.P.S: I'd like to verify my theory, but it only hangs for other people
and works fine here.

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D


signature.asc
Description: OpenPGP digital signature

Re: How do I detect a failure in Make?

[Doyle Rhynard]

Richard Quadling wrote:

On 26/04/06, mwoehlke <[EMAIL PROTECTED]> wrote:

Richard Quadling wrote:

I have the following bash script ...

#!/bin/sh
cvs up 2> $HOME/cvs1.log > $HOME/cvs2.log
cd phpdoc
autoconf -v -d --warnings=all &> $HOME/autoconf.log
./configure --with-source=./../php-src --with-pear-source=./../pear
--with-chm=yes --with-treesaving > $HOME/configure.log
make test > $HOME/make_test.log
make test_xml > $HOME/make_test_xml.log
make chm_xsl > $HOME/make_chm_xsl.log

Is there a way of stopping the makes if there was a problem.



Matthew said using [ $? -eq 0 ] || exit $? after each make line would work.


It doesn't. The issue is that the make function is crashing (the core
dump ??!!!??).

I'm not responsible for the construction of the make file, I just want
to stop my script from running if there is a problem.

--
-
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=UlF1YWRsaW5n


Use "remake" the make debugger 
It will allow you to step through the makefile and stop when an error is 
found.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rsync over ssh hang issue understood

[Steven Hartland]

Steven Hartland wrote:

Good news this does fix the issue. I've just successfully done
an rsync of ~1G ( 1700 files ) with no problem at all.

Also note that due to the existing performance issues in ssh ( I've
still not had chance to dig more about that sorry ) there is NO
noticable slowdown when comparing this version to the baseline
version of openssh.

All in all this version is a massive improvement which is fantastic
news!!!


Dam spoke too soon. The experimental version seems to loose output
sometimes, possibly not being flushed. Here's a reproductive sequence
for you.

freebsd1> ssh cygwin1
cygwin1> echo "1" > /tmp/test.txt
cygwin1> cat /tmp/test.txt
1
cygwin1> exit
freebsd1> ssh cygwin1 "cat /tmp/test.txt"
*** no output ***

Looks like its just not flushing the output at someone point in the
reworked code.

   Steve




This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone (023) 8024 3137
or return the E.mail to [EMAIL PROTECTED]


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Recovering after updating while cygwin was running

[Ido Trivizki]

I'm running windows XP. I accidently updated something (and probably 
cygwin1.dll too, I only tried to install another package..) while cygwin 
bash was running. Afterwards I couldn't run any cygwin application. I 
removed cygwin folder, registry keys, and any copy of cygwin1.dll I had on 
the hard drive, and reinstalled from scratch. And still, every app I try to 
run gives me something like:
"  7 [main] ? (3556) C:\cygwin\bin\bash.exe: *** fatal error - system 
shared

memory version mismatch detected - 0x75BE0074/0x75BE0096.
This problem is probably due to using incompatible versions of the cygwin 
DLL.

Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version 
*should*

reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL."

I repeated it several times with rebooting, and still I can't run anything. 
(Including cygcheck, pardon.)


Could you please help me?
Thanks,
Ido

_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Compiling with gettimeofday

[TV JOE]

i,
 
I've a program written for SUSE linux. The compile fails at the same 
place each time while referencing gettimeofday. I compile like this 
  
gcc -I/usr/include/mingw -I/usr/include/mingw/sys GoCart_v04.c -lm
  
I compile with and without the -I included dirs and still have the
problem. 
At compile I get this error message. 
  
v04.c: In function `gettime':
v04.c:196: error: storage size of 'ltim' isn't known

Here is funtion gettime. 
  

//
// Functions start here.
//

// Function to read system time.  Only used for testing execution speed.
long int gettime(void)
{
 struct timeval ltim;

  gettimeofday(

Re: Compiling with gettimeofday

[Brian Dessent]

TV JOE wrote:

> gcc -I/usr/include/mingw -I/usr/include/mingw/sys GoCart_v04.c -lm

Stop right there.  You should *never* do this.  This is like filling a
gasoline car's tank with diesel -- it will not work and it will cause
breakage.  Mingw is a completely separate environment from Cygwin, you
can't just go mixing bits and pieces of each.  They use radically
different C runtimes.

If you want to use mingw, you need to use -mno-cygwin.  The include
paths will be adjusted accordingly.

This is quite a red herring though, because there's no need to use mingw
to call gettimeofday().

Also, -lm is never needed with Cygwin and does nothing.

> // Function to read system time.  Only used for testing execution speed.
> long int gettime(void)
> {
>  struct timeval ltim;
> 
>   gettimeofday(   return (((long int)ltim.tv_sec)*((long int)(100))+((long
> int)ltim.tv_usec));
> }
> 
> My includes at the top of the
>  source code are as below.
> 
> // Inclusions
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> I've tried replacing time.h with unistd.h or including
> sys/time.h after time.h.  Any advice is welcome.

Rather than guesswork, why not look it up?  This is all standard stuff. 
It's defined by POSIX in the SUSv3. 
. 
Struct timeval is defined in sys/time.h.  Your testcase works fine as
follows:

$ cat gettimeofday.c
#include 

long int gettime(void)
{
 struct timeval ltim;

  gettimeofday(

OT?: tar --same-owner -xpf z.tar #"does rgt thing" in newdomain

[Tom Rodman]

We're migrating servers to a new AD domain.  The usernames are unchanged,
ie user accounts are duplicated in both domains, for the transition.

If foo.tar was created in domain "OLD", and as an admin, you run:

  tar --same-owner -xpf foo.tar  # in domain "NEW"

Then files and dirs are written out with ownership, and posix groups
mapped as one would hope - to the matching accounts and groups in
the new domain. Very nice!

--
thanks,
Tom Rodman

--
PS

A couple of days ago, after re-reading the tar info pages, I decided to
try the --same-owner switch , and was pleasantly surprised. Not sure if
it's commonly known that the --same-owner switch is needed even if your
an administrator. I had assumed "-xpf" was all that would be needed to
restore owners (like UNIX); when that did not work I "accepted" that
cygwin's tar did not restore ownership.

--
caveat:
  We're planning to setup SID history in the new domain, but to 
  my knowledge it is not in place now, so I think tar is looking
  up the SIDs in /etc/{password,group} using the names in the tar archive -
  ie I don't think I'm being fooled ;->

  Another side issue - initial tests in a separate "test domain", suggest
  that (as Corinna expected) cygwin does not understand SID history -
  I'm *not* saying it should.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/