Re: Bug in 'find' 4.2.11-CVS when traversing NTFS mount points

[Corinna Vinschen]

On Feb 22 14:21, Tim Hubberstey wrote:
> --- Corinna Vinschen wrote:
> > On Feb 18 09:58, Corinna Vinschen wrote:
> > > On Feb 17 01:52, Tim Hubberstey wrote:
> > > > $ find /cygdrive/c -name @@@F\*
> > > > find: Filesystem loop detected; `/cygdrive/c/aa/aa' has the same
> > device
> > > > number and inode as a directory which is 2 levels higher in the
> > > > filesystem hierarchy.
> > > 
> > > But I'm sure you don't want that.  [blah]
> > > Sorry, but there's currently no good solution for that.
> > 
> > In contrast to what I said, there seemed to have been a pretty simple
> > solution which doesn't slow down Cygwin at all.  Please try the
> > latest
> > developer snapshot from http://cygwin.com/snapshots .
> 
> Thanks! Snapshot 20050221 seems to have fixed the problem. 
> 
> Is snapshot 20050221 "safe" for regular use or should I back out of it?

Idealy there are not more bugs in the current snapshot than in the
current release.  But you won't get a guarantee.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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: coreutils wishlist

[Corinna Vinschen]

On Feb 22 21:52, Eric Blake wrote:
> The following two wishes are not essential, but would improve coreutils. 
> Unfortunately, I am not in a position to assign copyright to Red Hat at the 
> moment, so I can't contribute an implementation.

Too bad.  We could need help.

> POSIX requires statvfs() in , but cygwin currently only 
> provides statfs() in .  stat(1) can print more accurate 
> information from a working statvfs than it currently does with the existing 
> statfs interface.

Which is weird since statvfs doesn't contain much more information than
statfs.

> Linux provides /dev/full at major device 1, minor 7, and the properties of 
> world readable/writable, writes error out with ENOSPC, reads behave like 
> /dev/zero, seeks succeed.  The coreutils testsuite tries to use /dev/full 
> to ensure that utilities behave correctly in the face of write errors.  It 
> looks like it would not be too hard to extend the existing fhandler_zero 
> functionality into supporting /dev/full.

Did you try to create a symlink?

  mkdir -p /dev
  ln -s /dev/null /dev/full

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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: coreutils wishlist

[Corinna Vinschen]

On Feb 23 13:14, Corinna Vinschen wrote:
> On Feb 22 21:52, Eric Blake wrote:
> > Linux provides /dev/full at major device 1, minor 7, and the properties of 
> > world readable/writable, writes error out with ENOSPC, reads behave like 
> > /dev/zero, seeks succeed.  The coreutils testsuite tries to use /dev/full 
> > to ensure that utilities behave correctly in the face of write errors.  It 
> > looks like it would not be too hard to extend the existing fhandler_zero 
> > functionality into supporting /dev/full.
> 
> Did you try to create a symlink?
> 
>   mkdir -p /dev
>   ln -s /dev/null /dev/full

Ok, that doesn't help on writing.  I've implemented /dev/full now.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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: coreutils wishlist

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Corinna Vinschen on 2/23/2005 5:14 AM:
>>Unfortunately, I am not in a position to assign copyright to Red Hat at the 
>>moment, so I can't contribute an implementation.
> 
> Too bad.  We could need help.

Well, I'm willing; it is getting my employer to sign a disclaimer that is
holding me up at the moment.

> 
> 
>>POSIX requires statvfs() in , but cygwin currently only 
>>provides statfs() in .  stat(1) can print more accurate 
>>information from a working statvfs than it currently does with the existing 
>>statfs interface.
> 
> 
> Which is weird since statvfs doesn't contain much more information than
> statfs.

Well, CVS coreutils (but not 5.3.0) added stat -f -c"%s%S", to
differentiate between %s (optimum block size for fast transfers) and %S
(fundamental block size, or the size of a block on disk), based on
information in statvfs but not statfs.

Also, your first cut at  left out ST_RDONLY and ST_NOSUID.
 When you add those #defines, you might as well populate all the other
f_flag member bits with the ST_* namespace reserved to this header.

>>looks like it would not be too hard to extend the existing fhandler_zero 
>>functionality into supporting /dev/full.

Thanks for implementing that.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCHJBf84KuGfSFAYARApjSAJ4y/U///QNmkbAl26hkqloDQtbhdgCgj2/9
jKosbk5pKUgdPmVPOfohbqA=
=0vO5
-END PGP SIGNATURE-

--
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-agent and /tmp/ssh-* removal at logout

[Jim Kleckner]

ssh-agent leaves stale directories named /tmp/ssh-
that contain the named pipe for authentication.
These left over directories come about when you log out
or shut down the computer without stopping ssh-agent
either by running keychain to shut it down or sending it
a SIGHUP to exit and clean up.
Could ssh-agent catch the shutdown message and thus
do the proper cleanup?  What would that entail?
Jim
I noticed that in Karl's script to start keychain:
 http://sourceware.org/ml/cygwin/2004-03/msg00167.html
that he removes any /tmp/ssh-* pre-existing and presumed
stale directories left over by dead ssh-agent processes
and this assumes that there is only one ssh-agent per machine.
Not as good as actually getting rid of the source of the
zombie directories.
--
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/

1.5.12: FPU affected by gethostname call

[R . Schulz]

Dear cygwin team,

the following c++ program (see below) is affected by a strange bug: floating 
point precision is decreased by uncommenting the call to gethostname(). 

Behaviour:

* you get high precision if you do not call gethostname()
* you get different values if the call is uncommented, i.e. executed
* if you change the long doubles to normal doubles, values seem to be not 
affected by the gethostname call
* the resulting values for double precision are equal to the values obtained 
with long doubles in case the gethostname() function is invoked

This seems to happen on AMD Athlons and Opterons. I do not have an Intel system 
to test this behaviour on. Only OS tested was Windows XP SP1.

Thank you!

--> the program:

#include 
#include 

int main () 
{
   char name[100];
   // gethostname(name, 99); // UNCOMMENT THIS TO CHANGE BEHAVIOR

   const unsigned int n = 2;
   const unsigned int m = (n+1)/2;

   const long double tolerance = 5e-16;

   long double z = std::cos(3.1415 * (.75)/(n+.5));

   long   double pp;
   long   double p1, p2, p3;

   do
   {
  p1 = 1.;
  p2 = 0.;
  for (unsigned int j=0;j tolerance );
}

Cygwin Configuration Diagnostics
Current System Time: Wed Feb 23 15:06:16 2005

Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 2

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
.\
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\Programme\MiKTeX\miktex\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\matlab6p5\bin\win32
c:\Programme\Gemeinsame Dateien\Ulead Systems\MPEG
C:\cygwin\usr\local\lib\deal-devel\deal.II\lib

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1009(ralf) GID: 513(Kein)
513(Kein)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1009(ralf)  GID: 513(Kein)
0(root)  513(Kein)544(Administratoren)
545(Benutzer)

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

HOME = `C:\cygwin\home\ralf'
MAKE_MODE = `unix'
PWD = `/usr/local/lib/deal-devel/deal.II/examples/step-11'
USER = `ralf'

!EXITCODE = `'
ALLUSERSPROFILE = `C:\Dokumente und Einstellungen\All Users'
APPDATA = `C:\Dokumente und Einstellungen\ralf\Anwendungsdaten'
COMMONPROGRAMFILES = `C:\Programme\Gemeinsame Dateien'
COMPUTERNAME = `DEEPTHOUGHT-II'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
CVS_RSH = `/bin/ssh'
CYGWIN_ROOT = `\cygwin'
DISPLAY = `127.0.0.1:0.0'
FP_NO_HOST_CHECK = `NO'
HOMEDRIVE = `C:'
HOMEPATH = `\Dokumente und Einstellungen\ralf'
HOSTNAME = `DeepThought-II'
INFOPATH = 
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LOGNAME = `ralf'
LOGONSERVER = `\\DEEPTHOUGHT-II'
MANPATH = 
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/usr/local/lib/deal-devel/deal.II/examples'
OS = `Windows_NT'
P2 = 
`/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:.:/usr/bin:/usr/X11R6/bin:/cygdrive/c/Programme/MiKTeX/miktex/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/matlab6p5/bin/win32:/cygdrive/c/Programme/Gemeinsame
 Dateien/Ulead Systems/MPEG:/usr/local/lib/deal-devel/deal.II/lib'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 10 Stepping 0, AuthenticAMD'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0a00'
PROGRAMFILES = `C:\Programme'
PROMPT = `$P$G'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
SESSIONNAME = `Console'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `c:\DOKUME~1\ralf\LOKALE~1\Temp'
TERM = `xterm'
TERMCAP = `xterm-r6|xterm|xterm X11R6 
version:am:km:mi:ms:xn:co#80:it#8:li#24:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kd=\EOB:ke=\E[?1l\E>:kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:ta=^I:te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ue=\E[m:up=\E[A:us=\E[4m:kb=\010:'
TMP = `c:\DOKUME~1\ralf\LOKALE~1\Temp'
USERDOMAIN = `DEEPTHOUGHT-II'
USERNAME = `ralf'
USERPROFILE = `C:\Dokumente und Einstellungen\ralf'
WINDIR = `C:\WINDOWS'
WINDOWID = `2097166'
XAPPLRESDIR = `/usr/X11R6/lib/X11/app-defaults'
XCMSDB = `/usr/X11R6/lib/X11/Xcms.txt'
XKEYSYMDB = `/usr/X11R6/lib/X11/XKeysymDB'
XNLSPATH = `/usr/X11R6/lib/X11/locale'
_ = `/usr/bin/cygcheck'
POSIXLY_CORRECT = `1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\So

Re: cygpath -m (and -w) sometimes emits multi-line names

[Joshua Daniel Franklin]

On Tue, 22 Feb 2005 15:42:45 -, Dave Korn wrote:
> Original Message
> >From: cygwin-owner On Behalf Of Raul Miller
> > Both the man page and the usage information on cygpath indicate
> > that it only accepts a single file name argument.  These should
> > probably be updated.
> 
>   A fair point.  Attached :)
> 
>   Hmm.  Anyone out there know about utils.sgml better than me?  I have two
> questions:
> 
> 1)  Does it matter that the usage line is now longer than 80 chars?

Not really, but why not just put some on second line?
 
> 2)  What's with the CDATA section ?

A CDATA section is for enclosing text that might otherwise be interpreted as
formatting commands (i.e., special chars like > < & ), sort-of like
 in HTML.
Use it for code examples.
 
> Example cygpath usage
> 
> 
> 
> 
> 
>   When I look at the generated manpage in info or man, the opening  tag has disapperared.  I think it's
> probably not meant to be this way?

How are you generating man pages from that DocBook example? There is a way
to get man pages from  I think, but we don't use it for
Cygwin. I just wrote
a hacked-up perl script to turn utils.sgml into man pages.

--
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: coreutils wishlist

[Corinna Vinschen]

On Feb 23 07:17, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> According to Corinna Vinschen on 2/23/2005 5:14 AM:
> >>Unfortunately, I am not in a position to assign copyright to Red Hat at the 
> >>moment, so I can't contribute an implementation.
> > 
> > Too bad.  We could need help.
> 
> Well, I'm willing; it is getting my employer to sign a disclaimer that is
> holding me up at the moment.
> [...]
> Also, your first cut at  left out ST_RDONLY and ST_NOSUID.
>  When you add those #defines, you might as well populate all the other
> f_flag member bits with the ST_* namespace reserved to this header.

Hint:

Useful patches <= 10 lines (aka "trivial patches") are usually taken
w/o copyright assignment.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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: ssh-agent and /tmp/ssh-* removal at logout

[Corinna Vinschen]

On Feb 23 06:18, Jim Kleckner wrote:
> ssh-agent leaves stale directories named /tmp/ssh-
> that contain the named pipe for authentication.
> These left over directories come about when you log out
> or shut down the computer without stopping ssh-agent
> either by running keychain to shut it down or sending it
> a SIGHUP to exit and clean up.
> 
> Could ssh-agent catch the shutdown message and thus
> do the proper cleanup?  What would that entail?
> 
> Jim
> 
> I noticed that in Karl's script to start keychain:
>  http://sourceware.org/ml/cygwin/2004-03/msg00167.html
> that he removes any /tmp/ssh-* pre-existing and presumed
> stale directories left over by dead ssh-agent processes
> and this assumes that there is only one ssh-agent per machine.
> Not as good as actually getting rid of the source of the
> zombie directories.

But it's correct behaviour.  A forcefully killed process usually isn't
in the shape to make cleanup tasks.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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: 1.5.12: FPU affected by gethostname call

[Dave Korn]

-Original Message-
>From: cygwin-owner On Behalf Of R.Schulz
>Sent: 23 February 2005 14:28

>the following c++ program (see below) is affected by a strange bug:
floating 
>point precision is decreased by uncommenting the call to gethostname(). 

>* if you change the long doubles to normal doubles, values seem to be not
>affected by the gethostname call
>* the resulting values for double precision are equal to the values
obtained
>with long doubles in case the gethostname() function is invoked


  I'd bet the -ffloat-store flag makes a difference too.  This is a
well-known issue with x86 floating point implementations:

http://gcc.gnu.org/ml/gcc-help/2005-01/msg00173.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
http://gcc.gnu.org/ml/gcc-help/2005-02/msg00081.html
http://www.vinc17.org/research/extended.en.html
http://www.srware.com/linux_numerics.txt

http://www.google.co.uk/search?q=+site:gcc.gnu.org+x86+extended+precision+co
mpiler+problem&hl=en&lr=&client=firefox-a&rls=org.mozilla:en-US:official&sta
rt=20&sa=N

  To summarize:  inside the FP registers of the cpu, long doubles are stored
in extended (80-bit) precision format.  When these values have to be stored
to memory locations, however, they are truncated to 64 bits.  So you get
different results from a calculation depending if it's entirely done in
registers or if some of the intermediate results need to be spilled to the
stack, or otherwise stored in memory.

  In this case, the FP registers are presumably being saved and restored
owing to the call to gethostname, so that's why removing the call fixes it.

  If you use normal doubles, you're only ever working with 64-bit values, so
that's why changing to doubles gets the same result as long doubles with the
function call uncommented, even if the registers are not in this case
spilled to memory.


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: cygpath -m (and -w) sometimes emits multi-line names

[Dave Korn]

Original Message
From: cygwin-owner On Behalf Of Joshua Daniel Franklin
Sent: 23 February 2005 14:25


>> 2)  What's with the CDATA section ?
> 
> A CDATA section is for enclosing text that might otherwise be interpreted

  Yeh, I knew that!  I meant "How come it appears in the man page?"

>>   When I look at the generated manpage in info or man, the opening
>>  tag has disapperared.  I
>> think it's probably not meant to be this way?
> 
> How are you generating man pages from that DocBook example? There is a way
> to get man pages from  I think, but we don't use it for
> Cygwin. I just wrote
> a hacked-up perl script to turn utils.sgml into man pages.

  I'm not generating man pages myself; I was just looking at my installed
man and info pages, from .  Looks like there was a bug in your script!

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:

[real-story]

$B!ZA0!Y!'H~4u(B
$B!XG/Np!Y!'(B30$B:P(B
$B!X?&6H!Y!'<+1D6H(B
$B!XG/<}!Y!'(B2.400$BK|1_(B
$B!X%"%I:\$;$?$N$G%a!<%k$7$F$/$l$^$;$s$+!):#=5$J$i$$$D$G$b2q$($^$9!#(B
$B!!1g=u6b$O#1#0#0K|1_MQ0U$7$F$"$j$^$9!#(B
$B!y$3$A$i$+$iL5NAJV?.!y(B
(Bhttp://jellybean.hosting-geomax.jp/secret.php?pr=123456
$B"(8=:_!"H~4u$5$s$+$i$N;XL>%a!<%k$O5.J}MM$X$N0lDL$N$_$H$J$C$F$*$j$^$9!#(B
$B!y(Byahoo$B%"%I%l%9$J$I%U%j!<%a!<%k%"%I%l%9$+$i$G$bEPO?$G$-$^$9!y(B
$B!y$*$+$2$5$^$GA49qM%NI%5%$%H$KA*$P$l$^$7$?!#(B
$BB~:#!"46HV!&D>%"%I8+J|Bj!y(B
(B
(B
(B--
(BUnsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
(BProblem reports:   http://cygwin.com/problems.html
(BDocumentation: http://cygwin.com/docs.html
(BFAQ:   http://cygwin.com/faq/

Re: 1.5.12: FPU affected by gethostname call

[Ralf B. Schulz]

Long doubles are 12 byte = 96 bit = sizeof(long double). No matter whether 
stored in memory or in registers, they should have that length, no?

The -ffloat-store option does not make a difference (at least not in the first 
7 digits). However, there is a significant difference between the version 
calling gethostname() --> p1 results in 1.11022e-16 (or, if "tolerance" is 
set to 1e-19, it stops at p1 = -5.5e-17) and the version without that 
function call --> p1 results in 8e-17 (or, if "tolerance" is set to 1e-19, it 
goes right down to 0).

The program I mailed is an excerpt from a large project (the deal.II library, 
www.dealii.org) which runs fine on a lot of Linux and other Unix systems, on 
all kinds of processors and multiprocessor environments, but the part I sent 
you does not terminate if run under cygwin, in case gethostname() is called 
from _anywhere_ in the program. It doesn't even matter when gethostname() is 
called, its effect is visible after the call throughout the program (!).

In the case of the original program, gethostname() is called in some startup 
code, the loop causing the problems is called at some completely different 
point in the program. It seems unlikely that this should have an effect on 
whether or not variables are stored in registers.

In the original code, tolerance is set to 1e-19 instead of 5e-16 if long 
doubles are available. In this case, the code calling gethostname() goes into 
an infinite loop.

-Ralf

On Wednesday 23 February 2005 16:15, Dave Korn wrote:
> -Original Message-
> From: cygwin-owner On Behalf Of R.Schulz
>
> >Sent: 23 February 2005 14:28
> >
> >the following c++ program (see below) is affected by a strange bug:
>
> floating
>
> >point precision is decreased by uncommenting the call to gethostname().
> >
> >* if you change the long doubles to normal doubles, values seem to be not
> >affected by the gethostname call
> >* the resulting values for double precision are equal to the values
>
> obtained
>
> >with long doubles in case the gethostname() function is invoked
>
>   I'd bet the -ffloat-store flag makes a difference too.  This is a
> well-known issue with x86 floating point implementations:
>
> http://gcc.gnu.org/ml/gcc-help/2005-01/msg00173.html
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
> http://gcc.gnu.org/ml/gcc-help/2005-02/msg00081.html
> http://www.vinc17.org/research/extended.en.html
> http://www.srware.com/linux_numerics.txt
>
> http://www.google.co.uk/search?q=+site:gcc.gnu.org+x86+extended+precision+c
>o
> mpiler+problem&hl=en&lr=&client=firefox-a&rls=org.mozilla:en-US:official&st
>a rt=20&sa=N
>
>   To summarize:  inside the FP registers of the cpu, long doubles are
> stored in extended (80-bit) precision format.  When these values have to be
> stored to memory locations, however, they are truncated to 64 bits.  So you
> get different results from a calculation depending if it's entirely done in
> registers or if some of the intermediate results need to be spilled to the
> stack, or otherwise stored in memory.
>
>   In this case, the FP registers are presumably being saved and restored
> owing to the call to gethostname, so that's why removing the call fixes it.
>
>   If you use normal doubles, you're only ever working with 64-bit values,
> so that's why changing to doubles gets the same result as long doubles with
> the function call uncommented, even if the registers are not in this case
> spilled to memory.
>
>
> cheers,
>   DaveK

-- 
-
Ralf B. Schulz, Dipl.-Inform. Med

Functional and Molecular Emission Computed Tomography
Dept. E020 Medical Physics in Radiology
DKFZ -- German Cancer Research Center
Im Neuenheimer Feld 280
D-69120 Heidelberg, Germany

phone: ++49 (0) 6221 42-2606
fax:   ++49 (0) 6221 42-2572
web:   http://www.dkfz.de/en/medphysrad/ect/team/rschulz.html

--
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: ssh-agent and /tmp/ssh-* removal at logout

[Karl M]

From: Jim Kleckner
Subject: ssh-agent and /tmp/ssh-* removal at logout
Date: Wed, 23 Feb 2005 06:18:50 -0800
ssh-agent leaves stale directories named /tmp/ssh-
that contain the named pipe for authentication.
These left over directories come about when you log out
or shut down the computer without stopping ssh-agent
either by running keychain to shut it down or sending it
a SIGHUP to exit and clean up.
Could ssh-agent catch the shutdown message and thus
do the proper cleanup?  What would that entail?
Jim
I noticed that in Karl's script to start keychain:
 http://sourceware.org/ml/cygwin/2004-03/msg00167.html
that he removes any /tmp/ssh-* pre-existing and presumed
stale directories left over by dead ssh-agent processes
and this assumes that there is only one ssh-agent per machine.
Not as good as actually getting rid of the source of the
zombie directories.
Actually, it does not assume that there is only one ssh-agent process per 
machine. I routinely use it with ssh-agents processes for multiple users. 
The files for other users are protected so that they can not be deleted. 
Thus, only the current user's tmp files are deleted.

I'm in the process of doing some clean-up work and trying out keychain 
2.5.1. I am also adding ${HOSTNAME}.cmd file creation for use with Windows 
shell scripts. If there is interest, perhaps I should offer to maintain 
keychain, with additional support for launching it from a service. Launching 
keychain from a service allows the ssh-agent process to survive logout, so 
you only type a passphrase once per reboot instead of once per login.

Thanks,
...Karl

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

findutils 20041227-1: problem with find -printf %n

[Leonardo Vainsencher]

I would like to report that "find -printf %n" appends a spurious 'd' to the 
output produced.
This happens also for %G, %U, %b, %D, %k format directives.

Under Cygwin:
=
% cygcheck -v -s | grep ^find
findutils 20041227-1
% for i in G U b D k n; do
fmt="%12$i\t%f\n"
echo \"$fmt\":
find -maxdepth 1 -name Makefile -printf $fmt
done
"%12G\t%f\n":
 513d   Makefile
"%12U\t%f\n":
1001d   Makefile
"%12b\t%f\n":
   6d   Makefile
"%12D\t%f\n":
  3371281718d   Makefile
"%12k\t%f\n":
   3d   Makefile
"%12n\t%f\n":
   1d   Makefile

Under Linux (%D removed):
=
% for i in G U b k n; do
fmt="%12$i\t%f\n"
echo \"$fmt\":
find -maxdepth 1 -name Makefile -printf $fmt
done
"%12G\t%f\n":
1000Makefile
"%12U\t%f\n":
1000Makefile
"%12b\t%f\n":
  40Makefile
"%12k\t%f\n":
  20Makefile
"%12n\t%f\n":
   1Makefile

Looking at find/parser.c source (from findutils-20041227-1-src.tar.bz2) it 
appears
that a "break;" is missing at line 1777 in funcion
"static struct segment ** make_segment (struct segment **segment, char *format, 
int len, int kind)"

The result after adding the break statement:
===
% for i in G U b D k n; do
fmt="%12$i\t%f\n"
echo \"$fmt\":
/usr/src/findutils-20041227-1/find/find -maxdepth 1 -name Makefile -printf 
$fmt
done
"%12G\t%f\n":
 513Makefile
"%12U\t%f\n":
1001Makefile
"%12b\t%f\n":
   6Makefile
"%12D\t%f\n":
  3371281718Makefile
"%12k\t%f\n":
   3Makefile
"%12n\t%f\n":
   1Makefile

-- 
Leonardo Vainsencher
[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: ssh-agent and /tmp/ssh-* removal at logout

[Mark Paulus]

I think keychain as a service would be nice.  I currently
use a modified version of ssh-agent as a service, and 
it works pretty well.  I just have to remember to replace
the ssh-agent with my patched version any time the
ssh package gets updated.

And, yes, I have offered a patch upstream as well as the 
other guy who gave me the idea/pointers to where to patch
the ssh-agent code.

The issue is that the output from ssh-agent (the part that 
outputs the PID and SOCK data is put out on stdout, which
is bufferred, and does not get flushed under cygwin.  The
patch is to place a fflush statement after the output so that
when you redirect stdout to your .ssh-agent file, something 
actually appears within the file.

On Wed, 23 Feb 2005 08:41:13 -0800, Karl M wrote:



>>From: Jim Kleckner
>>Subject: ssh-agent and /tmp/ssh-* removal at logout
>>Date: Wed, 23 Feb 2005 06:18:50 -0800
>>
>>ssh-agent leaves stale directories named /tmp/ssh-
>>that contain the named pipe for authentication.
>>These left over directories come about when you log out
>>or shut down the computer without stopping ssh-agent
>>either by running keychain to shut it down or sending it
>>a SIGHUP to exit and clean up.
>>
>>Could ssh-agent catch the shutdown message and thus
>>do the proper cleanup?  What would that entail?
>>
>>Jim
>>
>>I noticed that in Karl's script to start keychain:
>>  http://sourceware.org/ml/cygwin/2004-03/msg00167.html
>>that he removes any /tmp/ssh-* pre-existing and presumed
>>stale directories left over by dead ssh-agent processes
>>and this assumes that there is only one ssh-agent per machine.
>>Not as good as actually getting rid of the source of the
>>zombie directories.
>>
>Actually, it does not assume that there is only one ssh-agent process per 
>machine. I routinely use it with ssh-agents processes for multiple users. 
>The files for other users are protected so that they can not be deleted. 
>Thus, only the current user's tmp files are deleted.

>I'm in the process of doing some clean-up work and trying out keychain 
>2.5.1. I am also adding ${HOSTNAME}.cmd file creation for use with Windows 
>shell scripts. If there is interest, perhaps I should offer to maintain 
>keychain, with additional support for launching it from a service. Launching 
>keychain from a service allows the ssh-agent process to survive logout, so 
>you only type a passphrase once per reboot instead of once per login.

>Thanks,

>...Karl



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





--
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: ssh-agent and /tmp/ssh-* removal at logout

[Jim Kleckner]

Corinna Vinschen wrote:
On Feb 23 06:18, Jim Kleckner wrote:
ssh-agent leaves stale directories named /tmp/ssh-
that contain the named pipe for authentication.
These left over directories come about when you log out
or shut down the computer without stopping ssh-agent
either by running keychain to shut it down or sending it
a SIGHUP to exit and clean up.
Could ssh-agent catch the shutdown message and thus
do the proper cleanup?  What would that entail?
[snip]
But it's correct behaviour.  A forcefully killed process usually isn't
in the shape to make cleanup tasks.
Corinna
I guess a better way of phrasing my question would be:
Many Windows applications receive a notification on logout or
shutdown that allows them to take an action prior to being
killed (including dialogs with the user).  Is there any practical
way to use this for ssh-agent (or other cygwin processes)?
For example, could the cygwin subsystem receive this notification
and send a SIGHUP to the process?  I'm guessing that the
answer is that it is not practical.
Jim
--
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: ssh-agent and /tmp/ssh-* removal at logout

[Corinna Vinschen]

On Feb 23 08:41, Karl M wrote:
> I'm in the process of doing some clean-up work and trying out keychain 
> 2.5.1. I am also adding ${HOSTNAME}.cmd file creation for use with Windows 
> shell scripts. If there is interest, perhaps I should offer to maintain 
> keychain, with additional support for launching it from a service. 

Did you talk with the Hack Kampbjorn, the Cygwin keychain maintainer
about that?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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: ssh-agent and /tmp/ssh-* removal at logout

[Karl M]

From: Jim Kleckner
Subject: Re: ssh-agent and /tmp/ssh-* removal at logout
Date: Wed, 23 Feb 2005 09:20:08 -0800
Corinna Vinschen wrote:
On Feb 23 06:18, Jim Kleckner wrote:
ssh-agent leaves stale directories named /tmp/ssh-
that contain the named pipe for authentication.
These left over directories come about when you log out
or shut down the computer without stopping ssh-agent
either by running keychain to shut it down or sending it
a SIGHUP to exit and clean up.
Could ssh-agent catch the shutdown message and thus
do the proper cleanup?  What would that entail?
[snip]
But it's correct behaviour.  A forcefully killed process usually isn't
in the shape to make cleanup tasks.
Corinna
I guess a better way of phrasing my question would be:
Many Windows applications receive a notification on logout or
shutdown that allows them to take an action prior to being
killed (including dialogs with the user).  Is there any practical
way to use this for ssh-agent (or other cygwin processes)?
For example, could the cygwin subsystem receive this notification
and send a SIGHUP to the process?  I'm guessing that the
answer is that it is not practical.
Jim
ssh-agent does not need to be aware of this. keychain can handle it. I 
currently trap the TERM signal in my keychain service and cleanly stop the 
ssh-agent via keychain, so it no longer leaves the tmp folders around.

Thanks,
...Karl

--
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: 1.5.12: FPU affected by gethostname call

[Dave Korn]

Original Message
>From: cygwin-owner On Behalf Of Ralf B. Schulz 
>Sent: 23 February 2005 16:42

> Long doubles are 12 byte = 96 bit = sizeof(long double). No matter whether
> stored in memory or in registers, they should have that length, no?

  Oh, that does turn out to be a recent change to gcc.  Hmm.

  Then again, I can't reproduce the problem here.  Maybe that's the AMD vs
Intel difference you were wondering about.  I've got a P4; same OS version
as you though, XpSp1.  It makes no difference if I have the call to
gethostname or not, and it makes no difference if I compile with or without
optimisation.

> In the original code, tolerance is set to 1e-19 instead of 5e-16 if long
> doubles are available. In this case, the code calling gethostname() goes
> into an infinite loop.

  That code is seriously buggy, isn't it?

const long double tolerance = 5e-16;
long   double p1, p2, p3;

   do
   {
   [details omitted]
   }
   while (abs(p1/pp) > tolerance);
  ^^

  I really think that ought to have been *f*abs, should it not?  

  Heh.  Why do people always think they can just ignore compiler warnings?

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: ssh-agent and /tmp/ssh-* removal at logout

[Karl M]

From: Corinna Vinschen >Reply-To: cygwin@cygwin.com
Subject: Re: ssh-agent and /tmp/ssh-* removal at logout
Date: Wed, 23 Feb 2005 18:21:00 +0100
On Feb 23 08:41, Karl M wrote:
> I'm in the process of doing some clean-up work and trying out keychain
> 2.5.1. I am also adding ${HOSTNAME}.cmd file creation for use with 
Windows
> shell scripts. If there is interest, perhaps I should offer to maintain
> keychain, with additional support for launching it from a service.

Did you talk with the Hack Kampbjorn, the Cygwin keychain maintainer
about that?
I have not talked with him recently. keychain 2.0.3 is pretty old, so I was 
not sure if he was still supporting it. If Hack wants to support keychain as 
a service, I can provide him with everything he needs...or I can support 
it...either way is fine with me.

Thanks,
...Karl

--
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 to bring job to foreground?

[Matt Wilkie]

> >and the console in which I suspended the script has not given me a
> >prompt so I can't issue any more commands.
> 
> What if you suspend it like "vi &" instead. That definitely gives me a
> prompt and the "fg" command works. 

In future that is what I will do, however in this circumstance when I
started the process I didn't know I was going to want to suspend it.
(I was about to run out of disk space so I tried to pause tar long
enough to let me make room. The pause worked, but I couldn't get it
restarted again).

-- 
-matt

--
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 to bring job to foreground?

[Matt Wilkie]

On Tue, 22 Feb 2005 18:17:26 -0800 (PST), Jeremy C. Reed
<[EMAIL PROTECTED]> wrote:
> On Tue, 22 Feb 2005, Matt Wilkie wrote:
> 
> > thanks for your help Jeremy.
> 
> You are welcome.
> 
> > Although -SIGCONT didn't completely work in this circumstance I'm glad
> > of the knowledge. I've encountered similar situations before and knew
> > there had to be _some_ way of reactivating a process from another
> > console. It never occured to read up on 'kill' in this context, what I
> > was attempting was precisely the opposite after all. :)
> 
> The strange thing I noticed with my tests with bash is that it still said
> job was suspended when really it was running (after the kill -SIGCONT).

Yeah, that's what I get too. I guess suspending apps with ctrl-z
instead of & on windows is still chancy.

-- 
-matt

--
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: perl & Win32 lib support

[Linda W]

Not knowing the exact order of how things are released,
does announcing it on "cygwin-apps" mean that it will be
available via setup soon?
When it is, does that mean we should be able to build perl
modules/utils that inter-operate with the native Win32
interface?  What necessary steps does it need on cygwin-apps
before it is released for public consumption?
Thanks,
-linda
Reini Urban wrote:
Yitzchak Scott-Thoennes schrieb:
3) wait for an updated perl-libwin32 release (should be soon)

It's already announced in cygwin-apps.
It just needs the necessary steps there.

--
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: perl & Win32 lib support

[Igor Pechtchanski]

On Wed, 23 Feb 2005, Linda W wrote:

> Reini Urban wrote:
>
> > Yitzchak Scott-Thoennes schrieb:
> >
> > > 3) wait for an updated perl-libwin32 release (should be soon)
> >
> > It's already announced in cygwin-apps.
> > It just needs the necessary steps there.
>
> Not knowing the exact order of how things are released, does announcing
> it on "cygwin-apps" mean that it will be available via setup soon?

Announcing something on cygwin-apps means that the other maintainers will
look at it if necessary, and that someone with access will eventually
upload it to sourceware.org.  Once that happens, the package will be
announced on cygwin-announce, and *that* does mean that it'll be available
via setup soon. :-)

> When it is, does that mean we should be able to build perl modules/utils
> that inter-operate with the native Win32 interface?

I'll let Reini answer this one.

> What necessary steps does it need on cygwin-apps before it is released
> for public consumption?

At the very least it needs to be uploaded to sourceware.org.  I'd wait for
it to appear on cygwin-announce before trying to download it via setup.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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 matplotlib under cygwin

[Kirschner, Paul E UTRC]

I am trying to install matplotlib-0.72.1 (matplotlib.sourceforge.net) under
cygwin and its python release.

I had to modify setupext.py to include the proper directories for cygwin (to
match linux)...

basedir = {
'win32'  : ['win32_static',],
'cygwin' : ['/usr/local', '/usr',],
'linux2' : ['/usr/local', '/usr',],
'linux'  : ['/usr/local', '/usr',],
'darwin' : ['/usr/local', '/usr', '/sw', '/usr/X11R6'],
'freebsd4' : ['/usr/local', '/usr'],
'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
}

The build "python setup.py build" fails with ...

creating build/temp.cygwin-1.5.12-i686-2.4/CXX
gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Isrc -I.
-I/usr/include/python2.4 -c src/_na_transforms.cpp -o
build/temp.cygwin-1.5.12-i686-2.4/src/_na_transforms.o -DNUMARRAY=1
D:\cygwin\bin\python2.4.exe (2140): *** unable to remap
D:\cygwin\bin\tk84.dll to same address as parent(0x71) != 0xB8
891 [main] python 2280 sync_with_child: child 2140(0x1E8) died before
initialization with status code 0x1
  11786 [main] python 2280 sync_with_child: *** child state child loading
dlls
error: Resource temporarily unavailable

What happened here? Any help in making this work?

thanks...


-
Paul Kirschner
Systems Department
United Technologies Research Center
[EMAIL PROTECTED]
(860)610-7119




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

packg mngmnt model & other cygwin package releases...(where did they come from?)

[Linda W]

Igor Pechtchanski wrote:
Announcing something on cygwin-apps means that the other maintainers will
look at it if necessary, and that someone with access will eventually
upload it to sourceware.org.  Once that happens, the package will be
announced on cygwin-announce, and *that* does mean that it'll be available
via setup soon. :-)
===
Ahhh...hmm...I haven't understood (and am not entirely sure, if
yet, I do) the package release mechanism.  I would have thought that
package maintainers would have been able to check in their packages
directly -- perhaps, at least, under the experimental release section.
If I understand you correctly, package maintainers first have
to announce something on cygwin-apps, then a few people who have
"cygwin-package approval" status eventually find the time to check in the
change?
If I understand the linux-kernel model, different folk who are
maintain a particular driver or subsystem are responsible for collecting
any suggested changes to their "package" and check in changes themselves --
a distributed delegation model, whereas, if I understand you correctly
package owners aren't delegated the authority to check in/release new
versions of their packages?
From what I gather, linus used to require all changes go through
him for pre-approval, but after it became "big enough", he was willing to
delegate check-in authority to specified package maintainers(?).
Isn't the cygwin project large enough to delegate peripheral
(non-core) package update/checkin or is the cygwin source management
model not flexible enough for this granularity?  Or does cygwin have a
need for each individual package to be checked in.
I wondered about this when I found a completely separate package
distribution (that appears to no longer be supported but was located
at http://gnuwin.epfl.ch/en/index.html).  Why didn't they just release
their packages through cygwin/setup?  Seems like they have a ton
(http://gnuwin.epfl.ch/apps/en/bestlist.html) of packages for cygwin,
so many that put together a CD of gnu apps that run on cygwin.
I'd never even heard about them before they went to "no maintenance"
mode...*sigh*...why weren't they developing under the standard
cygwin/setup package model?  I was just surprised by all the packages that
were available for cygwin outside of the cygwin project and wondered
why they felt a need to release their packages separately -- they sure
didn't get very good publicity -- I ran into them when I wanted to see
about "cdrecord" being ported to work under cygwin...Apparently it was,
at some point, as well as a bunch more utils.  Very strange.
They claim the release doesn't have a "maintainer" even though
many of the packages do.  Is it possible to "invite" them to participate
through the main cygwin site or was there some reason they would refuse?
Seems a shame to see so many utils go to waste...
-linda
--
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: packg mngmnt model & other cygwin package releases...(where did they come from?)

[Brian Dessent]

Linda W wrote:

> Ahhh...hmm...I haven't understood (and am not entirely sure, if
> yet, I do) the package release mechanism.  I would have thought that
> package maintainers would have been able to check in their packages
> directly -- perhaps, at least, under the experimental release section.
> 
> If I understand you correctly, package maintainers first have
> to announce something on cygwin-apps, then a few people who have
> "cygwin-package approval" status eventually find the time to check in the
> change?

No, you misunderstand.  Once the package has been approved the first
time, a maintainer can post a new version at any time in the future just
by saying "please upload new version x.y-z" and it is usually done by
someone with a sourceware account within a few hours.  There is no
approval or review involved.  Maybe you should actually review how this
all works before making long rants about it?

There is not the level of handholding that you invision.  In fact it's
even less now, as the new package policy is that any package that's
included in standard linux distros (I think debian is the one used as a
test) gets automatic approval.  All a new package requires is a GTG
review to make sure it's packaged competently.  Before, it required
votes from other package maintainers in addition to a review.

Your rant about "stuff not in cygwin" should be directed to the people
that decided not to contribute them.  In a lot of cases, someone wants
to "support" a package by making a single version of it available and
then never be seen again.  The cygwin project does not have many demands
of a "package maintainer" but the few demands that it does make require
that the person read cygwin-apps and generally be available when
problems arise.  For some people, that's too much, so they just post
junk on some site somewhere and ignore it until the heat death of the
universe.

In the specific case of cdrecord, check the archives.  It's been
discussed plenty.  There was a licensing issue.

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: compiling matplotlib under cygwin

[Jason Tishler]

On Wed, Feb 23, 2005 at 03:40:13PM -0500, Kirschner, Paul E wrote:
> What happened here? Any help in making this work?

See the following:


http://www.google.com/search?hl=en&q=unable+remap+same+address+parent+cygwin+python

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
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: 1.5.12: FPU affected by gethostname call

[R . Schulz]

Okay, sorry: the abs() function was defined as a template in the original code
for historical reasons:

template
number abs(number) ... and so forth

Changing to std::fabs() doesn't change anything in the behavior, however.

At least now I know it's probably AMD FPU related. 

-Ralf

> > Long doubles are 12 byte = 96 bit = sizeof(long double). No matter
> whether
> > stored in memory or in registers, they should have that length, no?
> 
>   Oh, that does turn out to be a recent change to gcc.  Hmm.
> 
>   Then again, I can't reproduce the problem here.  Maybe that's the AMD
> vs
> Intel difference you were wondering about.  I've got a P4; same OS
> version
> as you though, XpSp1.  It makes no difference if I have the call to
> gethostname or not, and it makes no difference if I compile with or
> without
> optimisation.
> 
> > In the original code, tolerance is set to 1e-19 instead of 5e-16 if
> long
> > doubles are available. In this case, the code calling gethostname()
> goes
> > into an infinite loop.
> 
>   That code is seriously buggy, isn't it?
> 
> const long double tolerance = 5e-16;
> long   double p1, p2, p3;
> 
>do
>{
>[details omitted]
>}
>while (abs(p1/pp) > tolerance);
>   ^^
> 
>   I really think that ought to have been *f*abs, should it not?  
> 
>   Heh.  Why do people always think they can just ignore compiler
> warnings?
> 
> cheers,
>   DaveK

--
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: ssh-agent and /tmp/ssh-* removal at logout

[Jim Kleckner]

Karl M wrote:
From: Jim Kleckner
Subject: ssh-agent and /tmp/ssh-* removal at logout
Date: Wed, 23 Feb 2005 06:18:50 -0800
ssh-agent leaves stale directories named /tmp/ssh-
that contain the named pipe for authentication.
These left over directories come about when you log out
or shut down the computer without stopping ssh-agent
either by running keychain to shut it down or sending it
a SIGHUP to exit and clean up.
Could ssh-agent catch the shutdown message and thus
do the proper cleanup?  What would that entail?
Jim
I noticed that in Karl's script to start keychain:
 http://sourceware.org/ml/cygwin/2004-03/msg00167.html
that he removes any /tmp/ssh-* pre-existing and presumed
stale directories left over by dead ssh-agent processes
and this assumes that there is only one ssh-agent per machine.
Not as good as actually getting rid of the source of the
zombie directories.
Actually, it does not assume that there is only one ssh-agent process 
per machine. I routinely use it with ssh-agents processes for multiple 
users. The files for other users are protected so that they can not be 
deleted. Thus, only the current user's tmp files are deleted.

I'm in the process of doing some clean-up work and trying out keychain 
2.5.1. I am also adding ${HOSTNAME}.cmd file creation for use with 
Windows shell scripts. If there is interest, perhaps I should offer to 
maintain keychain, with additional support for launching it from a 
service. Launching keychain from a service allows the ssh-agent process 
to survive logout, so you only type a passphrase once per reboot instead 
of once per login.

Thanks,
...Karl
Ah, I see.  I had assumed that persons logged in with Administrator
privileges would blow them all away.
Having the service seems like a nice arrow in the quiver.
I don't think I would want my personal keyring to persist
across my sessions, though.  Kind of like leaving the key
in the car ignition while parked.  I can see that it could be
useful for daemon processes though.
Jim
--
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: ssh-agent and /tmp/ssh-* removal at logout

[Karl M]

From: Jim Kleckner
Subject: Re: ssh-agent and /tmp/ssh-* removal at logout
Date: Wed, 23 Feb 2005 15:04:46 -0800
Karl M wrote:
From: Jim Kleckner
Subject: ssh-agent and /tmp/ssh-* removal at logout
Date: Wed, 23 Feb 2005 06:18:50 -0800
ssh-agent leaves stale directories named /tmp/ssh-
that contain the named pipe for authentication.
These left over directories come about when you log out
or shut down the computer without stopping ssh-agent
either by running keychain to shut it down or sending it
a SIGHUP to exit and clean up.
Could ssh-agent catch the shutdown message and thus
do the proper cleanup?  What would that entail?
Jim
I noticed that in Karl's script to start keychain:
 http://sourceware.org/ml/cygwin/2004-03/msg00167.html
that he removes any /tmp/ssh-* pre-existing and presumed
stale directories left over by dead ssh-agent processes
and this assumes that there is only one ssh-agent per machine.
Not as good as actually getting rid of the source of the
zombie directories.
Actually, it does not assume that there is only one ssh-agent process per 
machine. I routinely use it with ssh-agents processes for multiple users. 
The files for other users are protected so that they can not be deleted. 
Thus, only the current user's tmp files are deleted.

I'm in the process of doing some clean-up work and trying out keychain 
2.5.1. I am also adding ${HOSTNAME}.cmd file creation for use with Windows 
shell scripts. If there is interest, perhaps I should offer to maintain 
keychain, with additional support for launching it from a service. 
Launching keychain from a service allows the ssh-agent process to survive 
logout, so you only type a passphrase once per reboot instead of once per 
login.

Thanks,
...Karl
Ah, I see.  I had assumed that persons logged in with Administrator
privileges would blow them all away.
Having the service seems like a nice arrow in the quiver.
I don't think I would want my personal keyring to persist
across my sessions, though.  Kind of like leaving the key
in the car ignition while parked.  I can see that it could be
useful for daemon processes though.
Jim
I use it that way all the time, but I also have a password on my 
screensaver. So I have a good tradeoff between security and convenience.

Thanks,
...Karl

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

fortran .exe files

[Marta Ghidella]

Hello,

I am new to cygwin. 

I installed the fundamental packages and gcc and g77. I tried them in the 
cygwin console without problems.
Bash scripts work fine, piping works fine, no problems.

Then I tried to run command line programs that I had created with djgpp, and 
found the following: the programs whose source code was C and were created with 
djgpp gcc work fine, but fortran programs created with g77 make the cygwin 
console hang. 

Something seems to be wrong with my installation. 

Perhaps the way of invoking bash in the cygwin.bat file?
It is as follows:

bash --login -i

Could someone give me a hint as to what the problem may be?

Thanks a lot.

Marta

--
Marta E. Ghidella
Instituto Antartico Argentino
Cerrito 1248
1010 Buenos Aires - ARGENTINA
tel: +54-11-4812-6313
fax: +54-11-4813-7807
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: cygpath -m (and -w) sometimes emits multi-line names

[Joshua Daniel Franklin]

On Wed, 23 Feb 2005 15:26:18 -, Dave Korn wrote:
> Original Message
> From: cygwin-owner On Behalf Of Joshua Daniel Franklin
> Sent: 23 February 2005 14:25
> 
> >> 2)  What's with the CDATA section ?
> >
> > A CDATA section is for enclosing text that might otherwise be interpreted
> 
>   Yeh, I knew that!  I meant "How come it appears in the man page?"
> 
> >>   When I look at the generated manpage in info or man, the opening
> >>  tag has disapperared.  I
> >> think it's probably not meant to be this way?
> >
> > How are you generating man pages from that DocBook example? There is a way
> > to get man pages from  I think, but we don't use it for
> > Cygwin. I just wrote
> > a hacked-up perl script to turn utils.sgml into man pages.
> 
>   I'm not generating man pages myself; I was just looking at my installed
> man and info pages, from .  Looks like there was a bug in your script!

Yep, it's a bug... no wait, it's a feature! I, uh, purposefully did it
to teach people
about XML.

I've updated cygpath and utils.sgml in CVS and the website, and I'll be putting
together a new version of cygwin-doc soon:



Thanks for the catch, Raul, usage now indicates acceptance of multiple file 
names in the standard GNU [NAME...] form.

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