Re: tcsh can't find executables in Path with "wrong" case

[Corinna Vinschen]

On Sep 14 10:28, Shankar Unni wrote:
> Corinna Vinschen wrote:
> 
> >Cygwin tcsh does not share its hashing code with the Win32 version, it
> >uses the same code as all other OSes are using.  No other OS is using
> >case insensitive hashing, so doesn't Cygwin tcsh.
> 
> Thanks for the corrections.
> 
> But bash is clearly doing something right, as:

No, sorry.  Bash is doing something *different*, there's no right or wrong.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT 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: tcsh can't find executables in Path with "wrong" case

[Corinna Vinschen]

On Sep 14 19:42, Dave Korn wrote:
> Original Message
> >From: Shankar Unni
> >Sent: 14 September 2005 18:55
> 
> > Eric Blake wrote:
> > 
> >> You'd better check the permissions there.  What does
> >> 'getfacl /cygdrive/c/oracle/product/10.1.0/db_1/bin/EXP.EXE'
> >> show?
> > 
> > [~] 7. getfacl /cygdrive/c/oracle/product/10.1.0/db_1/bin/EXP.EXE
> > # file: /cygdrive/c/oracle/product/10.1.0/db_1/bin/EXP.EXE
> > # owner: shankar
> > # group: None
> > user::---
> > group::---
> > group:root:rwx
> > group:SYSTEM:rwx
> > mask:rwx
> > other:---
> > 
> > Not being terribly familiar with facl's, I'm unsure as to how to read
> > this. But I am listed as the owner. And I'm also a member of the
> > Administrators group on my system..
> 
> 
>   Fascinating fact of the day #2387:  The 'doze "Administrators" group does
> in fact _not_ have full and un-ACL'd access to everything.  Only
> NT_AUTHORITY\System can do that.

No, not even SYSTEM has this right.  If you remove read permission for
SYSTEM on your .ssh/authorized_keys file, you'll be unable to ssh into
your box using pubkey authentication.  I think that's really crazy, but
nobody has asked for my opinion, apparently...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT 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/

find does not find files

[cygwin . 20 . job]

Hi folks,

I have the problem that with the find command several file are not detected. I 
make a find /cygdrive/c to get all files on the partition c: but all files 
under the folder 
drwx--+ 21 F.Braunbeck Domänen-Benutzer 0 Aug 17 11:51 __TRANSFER__/
are not listed. I' am the owner of __TRANSFER__ and so all files under the 
folder should be shown.

Any idea what is going wrong?



IMPORTANT
There is no way to send an email direct to this mail address. 
Every Mail which is not send to cygwin@cygwin.com is automatically deleted.

Regards 

Franz


--
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: help on socket connexion

[Corinna Vinschen]

On Sep 15 01:13, znort wrote:
> Hello everybody,
> 
> Could U help me please it's very important of course :(

There's nobody called "U" on this list, sorry.

> I'm doing (trying exactly) a little client/serveur tcp programm.
> [...]
> Now If I run a sample client test with a loop which try to connect 64
> times to my server,
> it works... but with FD_SETSIZE limit, my server will hang after 64 fork.
> 
> Right, but now, always on client side :
> 
> If I try a loop with 32 connection, it's ok.
> then I stop all my clients connexion - the children on server side die (ok)
> 
> If I try to connect again 32 times with my client by running my test
> program again...
> I meet again the FD_SETSIZE limit !!!
> 
> I suppose I've forgotten something on server side but where ???

Could you provide us with a testcase which contains the bare minimum
of code to reproduce the problem, and which compiles and runs out of
the box, please?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT 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/

1.5.18: tclsh's glob and relative paths containing ".."

[Sebastian Schuberth]

Hi,

I'm running the following simple script under tclsh 8.4:

puts stdout [glob ../common/*.cpp]

For some reason this returns *absolute* paths to the matching files, e.g.

d:/Development/common/test.cpp

instead of the expected

../common/test.cpp

Using ActiveTcl and under Linux the script works as expected. Relative 
paths that do not contain ".." also work fine under all platforms, incl. 
Cygwin. Any insights?


--
Sebastian Schuberth

Cygwin Configuration Diagnostics
Current System Time: Thu Sep 15 10:52:39 2005

Windows XP Professional 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:\texmf\miktex\bin
d:\PROGRA~1\CMake\bin
c:\WINDOWS
c:\WINDOWS\system32
c:\WINDOWS\System32\Wbem
d:\Development\Libraries\IPP\ia32_itanium\bin
d:\Development\Libraries\IPP\ia32_itanium\bin\win32
c:\Program Files\Common Files\Compuware\
c:\Program Files\Common Files\Compuware\NMShared
c:\Program Files\Common Files\GTK\2.0\bin
d:\Program Files\Intel C++ Compiler\IDB80\Bin
C:\cygwin\bin
d:\Program Files\Ghostscript\gs8.50\bin
d:\Program Files\MOVEit
d:\Development\Libraries\The Image Debugger
d:\Development\Libraries\DirectX SDK\Utilities\Bin\x86
d:\Program Files\doxygen\bin
d:\Tools

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 45386(sschuber)GID: 10545(mkgroup-l-d)
0(root) 544(Administrators) 545(Users)
10545(mkgroup-l-d)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 45386(sschuber)GID: 10545(mkgroup-l-d)
0(root) 544(Administrators) 545(Users)
10545(mkgroup-l-d)

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

USER = `sschuber'
PWD = `/cygdrive/d/Development/CVS-ZIB/amira/src/visage/vsreconfbpcb'
HOME = `/home/sschuber'
MAKE_MODE = `unix'

HOMEPATH = `\'
APPDATA = `C:\Documents and Settings\sschuber\Application Data'
MANPATH = 
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
VS71COMNTOOLS = `C:\Program Files\Microsoft Visual Studio .NET 
2003\Common7\Tools\'
VSINSTALLDIR = `C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE'
HOSTNAME = `XP-LSG-BERLIN2'
DXSDK_DIR = `D:\Development\Libraries\DirectX SDK\'
INTEL_LICENSE_FILE = `C:\Program Files\Common Files\Intel\Licenses'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 3 Stepping 4, GenuineIntel'
TERM = `cygwin'
WINDIR = `C:\WINDOWS'
USERDOMAIN = `MERCURY'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
OS = `Windows_NT'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
TEMP = `/cygdrive/c/DOCUME~1/sschuber/LOCALS~1/Temp'
VCINSTALLDIR = `C:\Program Files\Microsoft Visual Studio .NET 2003'
LIB = 
`D:\Development\Libraries\Integrated_Performance_Primitives-v4.1\ia32_itanium\lib;D:\Development\Libraries\Integrated_Performance_Primitives-v4.1\ia32_itanium\stublib'
USERNAME = `sschuber'
VISAGE_REQUIRE_QUADRO = `0'
PROCESSOR_LEVEL = `15'
FP_NO_HOST_CHECK = `NO'
SYSTEMDRIVE = `C:'
CLIENTNAME = `Console'
USERPROFILE = `C:\Documents and Settings\sschuber'
LOGONSERVER = `\\AD-BER1'
PS1 = `\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
PROCESSOR_ARCHITECTURE = `x86'
SHLVL = `1'
AMIRA_NO_LICENSE_MESSAGE = `1'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
USERDNSDOMAIN = `AD.MC.COM'
HOMEDRIVE = `U:'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
SYSTEMROOT = `C:\WINDOWS'
TMP = `/cygdrive/c/DOCUME~1/sschuber/LOCALS~1/Temp'
PROCESSOR_REVISION = `0304'
CVS_RSH = `/bin/ssh'
PRINTER = `FinePrint'
PROGRAMFILES = `C:\Program Files'
INFOPATH = 
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
HOMESHARE = `\\ad-fs1\sschuber'
NUMBER_OF_PROCESSORS = `2'
INCLUDE = 
`D:\Development\Libraries\Integrated_Performance_Primitives-v4.1\ia32_itanium\include'
INTEL_COMPILER80 = `D:\Program Files\Intel C++ Compiler\Compiler80'
VISAGE_TEXMEM = `384m'
SESSIONNAME = `Console'
COMPUTERNAME = `XP-LSG-BERLIN2'
_ = `/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 = 0x0028
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:\cygwin'
  flags = 0x0008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:\cygwin/bin'
  flags = 0x0008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:\cygwin/lib'
  flags = 0x0008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS

RE: find does not find files

[Tino.Engel]

Hi folks,

I have the problem that with the find command several file are not detected. I 
make a find /cygdrive/c to get all files on the partition c: but all files 
under the folder 
drwx--+ 21 F.Braunbeck Domänen-Benutzer 0 Aug 17 11:51 __TRANSFER__/
are not listed. I' am the owner of __TRANSFER__ and so all files under the 
folder should be shown.

Any idea what is going wrong?

Hi, no idea..
I reconstructed the situation, and it is working for me. So it is not a problem 
of the find comman probably. (At least, if your cygwin is the lates version)
The files in __TRANSFER__ are shown.
Does 'whoami' output F.Braunbeck?


--
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: Re: testers needed prior to 1.5.19 release

[Ralf Beck]

Chris,

No it was no problem with 1.5.18 as I could verify. Maybe my writing
was not explicit enough. The snapshot 20050914 is definitely okay 
in this respect. There is no 60 sec delay when I exit rxvt. 
Current cygcheck output as requested anyway included.

Thank you, Ralf Beck

On Tue, 13 Sep 2005 18:16:16 -0400, Christopher Faylor wrote:
>Could you provide cygcheck output as per http://cygwin.com/problems.html ?
>Your cygcheck output was lacking some details, unfortunately.
>
>Could you also verify that this isn't a problem with 1.5.18?  The above
>doesn't sound extremely definite to me.
>
>Finally, could see if the 2005-Sep-12 snapshot shows the same problems?
>
>cgf
>On Tue, Sep 13, 2005 at 11:18:08PM +0200, Ralf Beck wrote:
>
>>This is a report regarding cygwin1.dll
>>version "1.5.19" BuildDate "2005-09-13 15:40":
>>
>>In my .bash_profile I am using:
>>
>>  keychain --quiet ~/.ssh/id_rsa
>>  . ~/.keychain/${HOSTNAME}-sh
>>
>>I am also starting rxvt.exe with:
>>
>>  D:\cygwin\bin\rxvt.exe -sl 1000 -e bash -l
>>
>>When I exit rxvt it says "logout" and the window
>>will only be closed after 60 seconds.
>>
>>I was not not aware of this delay in the 
>>previous version "1.5.18" build "2005-07-02 20:30".
Cygwin Configuration Diagnostics
Current System Time: Thu Sep 15 10:51:16 2005

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   .\
D:\cygwin\home\ralf\bin
D:\cygwin\usr\local\bin
D:\cygwin\bin
D:\cygwin\bin
D:\cygwin\usr\X11R6\bin
d:\WINDOWS\system32
d:\WINDOWS
d:\WINDOWS\System32\Wbem
d:\Programme\ATI Technologies\ATI Control Panel
d:\Programme\Symantec\pcAnywhere\

Output from D:\cygwin\bin\id.exe (nontsec)
UID: 1003(ralf)  GID: 513(Kein)
0(root)  513(Kein)544(Administratoren)
545(Benutzer)

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

SysDir: D:\WINDOWS\system32
WinDir: D:\WINDOWS

USER = `ralf'
PWD = `/home/ralf'
HOME = `/home/ralf'
MAKE_MODE = `unix'

HOMEPATH = `\Dokumente und Einstellungen\ralf'
MANPATH = `/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = `D:\Dokumente und Einstellungen\ralf\Anwendungsdaten'
SSH_AGENT_PID = `2688'
HOSTNAME = `nt1'
TERM = `xterm'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 12 Stepping 0, AuthenticAMD'
WINDIR = `D:\WINDOWS'
WINDOWID = `4730176'
OLDPWD = `/usr/bin'
USERDOMAIN = `NT1'
OS = `Windows_NT'
ALLUSERSPROFILE = `D:\Dokumente und Einstellungen\All Users'
TEMP = `/cygdrive/d/DOKUME~1/ralf/LOKALE~1/Temp'
COMMONPROGRAMFILES = `D:\Programme\Gemeinsame Dateien'
SSH_AUTH_SOCK = `/tmp/ssh-F8eyvI91pp/agent.2664'
USERNAME = `ralf'
PROCESSOR_LEVEL = `15'
FP_NO_HOST_CHECK = `NO'
SYSTEMDRIVE = `D:'
USERPROFILE = `D:\Dokumente und Einstellungen\ralf'
CLIENTNAME = `Console'
PS1 = `\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = `\\NT1'
PROCESSOR_ARCHITECTURE = `x86'
MANPAGER = `less -R'
SHLVL = `1'
COLORFGBG = `0;default'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = `D:'
COMSPEC = `D:\WINDOWS\system32\cmd.exe'
TMP = `/cygdrive/d/DOKUME~1/ralf/LOKALE~1/Temp'
SYSTEMROOT = `D:\WINDOWS'
PRINTER = `\\rbsoft\lj4p'
CVS_RSH = `/bin/ssh'
PROCESSOR_REVISION = `0c00'
INFOPATH = `/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = `D:\Programme'
DISPLAY = `localhost:0.0'
NUMBER_OF_PROCESSORS = `1'
SESSIONNAME = `Console'
COMPUTERNAME = `NT1'
COLORTERM = `rxvt-xpm'
_ = `/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:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `D:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `D:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

a:  fd N/AN/A
b:  fd N/AN/A
c:  hd  NTFS   133Mb   8% CP CS UN PA FC 
d:  hd  NTFS 38020Mb  53% CP CS UN PA FC 
e:  cd  CDFS 1Mb 100%CS UN   MT86P_160
f:  fd N/AN/A
g:  fd N/AN/A
h:  fd N/AN/A
i:  fd N/AN/A
m:  net NTFS 61438Mb  80% CP CSPAmultimedia
n:  net NTFS 10239M

Bug in gcc and/or binutils?

[Peter Ekberg]

Hi!

I have been looking at a failure in the testsuite in
libtool-cvs which I have reduced to the following
script. I have included the approximate output from
any program execed by it in comments along with
comments as to what is going wrong.

$ gcc --version | head -1
gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
$ ld --version | head -1
GNU ld version 2.16.91 20050610

Etc etc yada yada updated the Cygwin installation the
other day...

This limitation is perhaps already known?

Cheers,
Peter

---8<---
#!/bin/bash
run ()
{
echo $*
eval $*
}
cat << EOF > a.c
const char* v7 = "foo";
EOF
cat << EOF > main.c
extern const char *v7;
int main(void)
{
  return *v7 - 'f';
}
EOF
cat << EOF > a.def
EXPORTS
v7
EOF
run gcc -c a.c -o a.o
run gcc -c main.c -o main.o
run gcc -shared a.def a.o -o a.dll -Wl,--out-implib,a.bad.lib
#Creating library file: a.bad.lib
run gcc -o bad main.o a.bad.lib
run ./bad
#Segmentation fault (core dumped)
echo returns: $?
#returns: 139
run cp a.dll a.temp.dll

# Experiments reveal that removing a.def from the dll linking
# stage makes it work, like this:

run gcc -shared a.o -o a.dll -Wl,--out-implib,a.good.lib
#Creating library file: a.good.lib
run gcc -o good main.o a.good.lib
#Info: resolving _v7 by linking to __imp__v7 (auto-import)
run ./good
echo returns: $?
#returns: 0

# Further experiments reveal that it is the import lib that is
# the culprit (as the missing Info message in the failing run
# hints at), like this:

run ./bad
#Segmentation fault (core dumped)
echo returns: $?
#returns: 139

# I.e. The exe generated with the bad import lib fails even
# if used with the known working dll.

run cp a.temp.dll a.dll
run ./good
echo returns: $?
#returns: 0

# I.e. The exe generated with the good import lib succeeds even
# if used with the dll from the failing run. So the dll isn't
# bad.

# Ergo, the import lib is bad. Comparing nm output from the two
# import libs reveals a significant difference:

run "nm a.bad.lib > a.bad.nm"
run "nm a.good.lib > a.good.nm"
run diff a.bad.nm a.good.nm
#23c23
#<  T _v7
#---
#>  I __nm__v7
---8<---

--
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: A new day, a new snapshot, more testing required on the road to 1.5.19

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Christopher Faylor on 9/14/2005 11:01 AM:
> It would be particularly nice if package maintainers would test their packages
> with a snapshot.  This is particularly important for Cygwin/X.  Historically,
> we often seem to find about problems after a release over there.  I've cc'ed
> the cygwin-xfree mailing list for this reason.

I tested 20050914 20:32:51 (the most recent at the time of this email) on
Win98, and was succefully able to use ssh, rebuild CVS coreutils, and
close the console, without seeing any stray processes.  There is still a
problem I reported earlier with strace popping up 3 error boxes when
trying to run 'strace -o strace.txt cvs up' in a directory where cvs uses
an ssh connection to the server, but I can live with that if you were to
release 1.5.19 now.

I also tested on WinXP, and didn't notice any problems in my usage patterns.

Since this is not a bug report, I'm not attaching any cygcheck output.
Thanks for all your efforts in chasing snapshot bug reports - I think cgf
deserves a gold star for putting up with all the incomplete regression
reports, and still fixing regressions anyways (that is, if I have any
right to nominate for a gold star).

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

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

iD8DBQFDKXhi84KuGfSFAYARAuuNAJ9W2MExI2NToeHxf2rn8IQC5sbrCACdEyEr
HWNNX7rrUP7aPyUNqUsAgaY=
=njZ0
-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/

[ANNOUNCEMENT] Updated: more-2.11o-2

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A new release of more, 2.11o-2, is available.

NEWS:
=
This is a minor bugfix release - more was recompiled against newer
versions of libraries so that it can now access large files and no longer
has the security flaw of the older regular expression parser libpcre.

This package is in need of adoption; I only uploaded a recompilation of a
3-year-old snapshot as a service to fix installation difficulties since
the old version depended on the now-obsolete libpcre.  Meanwhile, the
upstream sources that more was extracted from (the util-linux collection)
have reached version 2.13.  If you don't like how more was packaged, or
want to pick up the upstream patches to more from the newer util-linux,
then consider volunteering to be the maintainer.

DESCRIPTION:

More is a minimal pager.  It is provided because POSIX requires more and
some old scripts depend on more existing, although it does not yet
implement all POSIX-required features.  You are probably better off using
the 'less' package for your pager.

UPDATE:
===
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.
Save it and run setup, answer the questions and pick up 'more' from
the 'Text' category.

DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need to
find a mirror which has this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

- --
Eric Blake

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to 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.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDKXZy84KuGfSFAYARAqJYAJoCQTp6lputtxZh3q1UNpSD2iZo6ACfZn1x
X1bpxvYjwvQEp49nNhXGeik=
=YM3w
-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/

Re: A new day, a new snapshot, more testing required on the road to 1.5.19

[Christopher Faylor]

On Thu, Sep 15, 2005 at 12:55:20AM -0400, Volker Quetschke wrote:
>>>Can you duplicate this hang at will or does it take a full run of an 
>>>OpenOffice
>>>build to tickle it?
>>
>>So far (two cases) it hang in different places. It happened a few hours
>>into the build :( But I'll try to reproduce a small testcase tomorrow.
>
>I got a third hang in the same spot as the second and was able to create
>a somewhat large testcase.
>
>The following is a reduced (well 9MB zipped, 54MB unzipped) testcase for a
>hang when building OOo with cygwin snapshots 20050913 and 20050914(both).
>
>To reproduce get hang.zip from
> 
>to c:\ and start loop.csh.
>
>$ cd /cygdrive/c/solver/
>
>$ ./loop.csh
>loop
>Thu Sep 15 00:28:01 2005
>(nothing, no output) .
>
>You will see in the windows task manager that cppumaker is doing something
>but then it will hang. cppumaker will vanish from task manager but a 
>"zombie"
>perl will remain. This perl will not be mentioned in the ps output.
>
>If you CRTL-Z the script and start ps you will still see the cppumaker 
>process.

I got this working after downloading msv[pr]71.dll, but I just
repeatedly get this error:

  Thu Sep 15 10:01:48 EDT 2005
  j:\tmp\solver\cppumaker.exe : init registries failed, check your registry 
files.

without a hang.  Is there something I should be setting up in the registry?

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: Cygwin build system SOOOO SLOOOWWWW ???

[Jan Schormann]

Steve,

we've been struggling with speeding up our build process, too, so I'd
like to share some ideas - yet I'm not so certain whether you'll learn
from me or I'll learn from you: Hopefully both.

You wrote on Wednesday, September 14, 2005 3:45 AM:

> Greetings To All,
> 
> We've been using Cygwin for many years to host our software build
> system on Win32.  The system is built on top of gmake.

Same here.

>  We use the
> same gmake system on MacOSX, Linux, and Solaris.  Building under
> Cygwin has always been slower than on true *nix platforms.

We don't even do that. (Unfortunately,) our products are all-Windoze.
We switched to gmake because no other make tool was able to handle
our configurations the way we want. (Don't even ask me about
Virual Studio.)

> In the last year or so, however, the Cygwin port has gotten slower
> and slower, to the point that building the PC version of our software
> is PAINFUL.

I haven't noticed that, at least not to such extremes.

>  We've been changing the system, so maybe it's due to
> something we've added, but the other platforms remain speedy.  This
> leads me to two flavors of questions for the group...

Let's see ...

> 1) How can I tell what Cygwin is doing?  Is there a tool that will
> tell me what tool is actually running at any given time?  Is there
> any way to tell what Cygwin is doing down in its guts?  Does anyone
> have any other suggestions as to how I might get to the
> bottom of this?

Below, I'll tell about some suspicions I have about what cygwin might
actually be doing. To your question, I can offer two Ideas:

- "top" or any Windoze Process Explorer more sophisticated than
  the task manager
- "strace" - though I haven't ever used it, but from what I know
  this will definitely give you an answer - maybe two much of it ;-)

> 2) Has anyone else experienced speed problems with Cygwin?  Has
> anybody else felt that Cygwin has gotten slower over the last
> year or so?  Are there any guidelines or "tricks" for getting
> Cygwin to run faster? 

a) Forking is more expensive in Windoze.
On Unix, especially in make environments, you'll often start new
processes as you're going - and often you'll not even notice. Google
for "bash tricks" on how to fork less often.
Hint: Don't use "sed" in `backticks` just for simple string
replacements.
Much of this can be done in make or bash directly.
Look at the changes you made - maybe you thought it's more elegant?

b) This is especially true for shells.
I'm not really sure on when and where this hits, but under certain
circumstances, bash needs to parse /etc/passwd when it starts. Do
you create /etc/passwd from an LDAP directory using mkpasswd?
Maybe you have hired some more people last year and it got longer?
Hint: Try whether it makes a difference if you replace /etc/passwd
with one that contains only the local users (look at the options for
mkpasswd).

c) /bin/sh is now bash, which is now dynamically linked.
Up until a few months ago, /bin/sh has been "ash", a smaller, but
less powerfull shell. This has been replaced by bash, to reduce the
traffic of repeated questions along the lines of "why does my shell
act different than on linux" (where /bin/sh is bash on most
distributions).
If I understood the traffic on this list correctly, bash is now
dynamically
linked, which might have an impact on starting it - I can't tell.
Hint: Don't start bash so often. Create fewer processes, but if you
must, see if you gain by using ash explicitely instead of bash.

To the gurus - is the following correct?
`echo blub` starts one process, `echo blub | sed -e 's/b/x/g'`
starts three: "echo", "sed", and "bash" to implement the pipe.

d) Beware of lazy evaluation.
Look at this construct:
CFLAGS=$(shell find . -type d -name include)
Read "info make" on setting variables and find out about the
difference between "=" and ":=". The above will run the find
again for every single call to the compiler. Along with the
issues about forking and reading directories and small files,
this can make a difference of *ages*.
Hint: See whether you can use less variables, use ":=" more often,
etc. - and don't use "$(shell ...)" anyway, as stated in a).
Rather, pre-compute makefiles with all the data hardcoded, using
":=".

e) Reading lots of small files seems more expensive on Windoze.
I don't know about your Makefiles, but traditionally, makefiles are
spread across project directories (for build hierarchies), and
makedepend
creates even more of that. For one of our applications, I roughly
calculated that make needs to open, read, and parse well over a
thousand files (not counting the source or objects or any such thing,
just the makefiles), just for telling you that all the targets are
up to date.
Hint: Phew ...

You see, for our configurations, running make to tell me that *nothing*
has changed could take up to half an hour. Therefore we introduced some
magic using Python to generate and split up makefiles two years ago,
and were down below five minu

Re: A new day, a new snapshot, more testing required on the road to 1.5.19

[Volker Quetschke]

$ ./loop.csh
loop
Thu Sep 15 00:28:01 2005
(nothing, no output) .

You will see in the windows task manager that cppumaker is doing something
but then it will hang. cppumaker will vanish from task manager but a
"zombie"
perl will remain. This perl will not be mentioned in the ps output.

If you CRTL-Z the script and start ps you will still see the cppumaker
process.


I got this working after downloading msv[pr]71.dll, but I just
repeatedly get this error:

  Thu Sep 15 10:01:48 EDT 2005
  j:\tmp\solver\cppumaker.exe : init registries failed, check your registry 
files.

without a hang.  Is there something I should be setting up in the registry?


Drats, it must pick up something else from my build environment. No,
it's not a windows registry setting, it has something to do with these
*.rdb files.

Sorry, I'll try to get this testcase to run on a computer that has never
seen an OOo build environment.

Volker

--
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: A new day, a new snapshot, more testing required on the road to 1.5.19

[Volker Quetschke]

$ ./loop.csh
loop
Thu Sep 15 00:28:01 2005
(nothing, no output) .

You will see in the windows task manager that cppumaker is doing something
but then it will hang. cppumaker will vanish from task manager but a
"zombie"
perl will remain. This perl will not be mentioned in the ps output.

If you CRTL-Z the script and start ps you will still see the cppumaker
process.



I got this working after downloading msv[pr]71.dll, but I just
repeatedly get this error:

  Thu Sep 15 10:01:48 EDT 2005
  j:\tmp\solver\cppumaker.exe : init registries failed, check your registry 
files.


I forgot to mention that you have to adjust the path in loop.csh:

./guw.pl cppumaker -Gc -L -BUCR -O. \
/solver/680/wntmsci10.pro/bin/types.rdb


without a hang.  Is there something I should be setting up in the registry?


I got it to run without the "init registries failed, check your registry
files" problem on a computer that has never seen an OOo environment.

Unfortunately it is in iteration 10 right now and didn't fail :(
(This is a Celeron M 1.3 GHz Notebook.)

It failed before on an Athlon XP1700 (Win2k) and Opteron 850 (Win XP)
it the first iteration.

You shall not create statistics with two samples :(

Volker

--
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: Cygwin build system SOOOO SLOOOWWWW ???

[Igor Pechtchanski]

On Thu, 15 Sep 2005, Jan Schormann wrote:

> Let's see ...
>
> > 1) How can I tell what Cygwin is doing?  Is there a tool that will
> > tell me what tool is actually running at any given time?  Is there
> > any way to tell what Cygwin is doing down in its guts?  Does anyone
> > have any other suggestions as to how I might get to the
> > bottom of this?
>
> Below, I'll tell about some suspicions I have about what cygwin might
> actually be doing. To your question, I can offer two Ideas:
>
> - "top" or any Windoze Process Explorer more sophisticated than
>   the task manager
> - "strace" - though I haven't ever used it, but from what I know
>   this will definitely give you an answer - maybe two much of it ;-)

You can give strace command-line options to show only the kinds of events
you want...  See the strace help (or
).

> > 2) Has anyone else experienced speed problems with Cygwin?  Has
> > anybody else felt that Cygwin has gotten slower over the last
> > year or so?  Are there any guidelines or "tricks" for getting
> > Cygwin to run faster?
>
> a) Forking is more expensive in Windoze.
> On Unix, especially in make environments, you'll often start new
> processes as you're going - and often you'll not even notice. Google
> for "bash tricks" on how to fork less often.

Forking is not as expensive in Windows as it is in Cygwin (especially if
you fork off a Windows process, since Cygwin creates a stub for that).
.

> Hint: Don't use "sed" in `backticks` just for simple string
> replacements.
> Much of this can be done in make or bash directly.
> Look at the changes you made - maybe you thought it's more elegant?

FWIW, much of this can be done directly in "make". :-)

> b) This is especially true for shells.
> I'm not really sure on when and where this hits, but under certain
> circumstances, bash needs to parse /etc/passwd when it starts. Do
> you create /etc/passwd from an LDAP directory using mkpasswd?

*bash* itself never parses /etc/passwd.  Cygwin does -- every Cygwin
process looks at /etc/passwd on startup.  The first Cygwin process
actually reads it, and the rest simply check whether it changed.

However, that's just a file stat -- it doesn't actually query the domain
or LDAP directory (at least after the first invocation -- it does query
the current user then, but I don't think it does that for all users).

> Maybe you have hired some more people last year and it got longer?
> Hint: Try whether it makes a difference if you replace /etc/passwd
> with one that contains only the local users (look at the options for
> mkpasswd).

This shouldn't make a difference for multiple forks.

> c) /bin/sh is now bash, which is now dynamically linked.
> Up until a few months ago, /bin/sh has been "ash", a smaller, but
> less powerfull shell. This has been replaced by bash, to reduce the
> traffic of repeated questions along the lines of "why does my shell
> act different than on linux" (where /bin/sh is bash on most
> distributions).
> If I understood the traffic on this list correctly, bash is now
> dynamically linked, which might have an impact on starting it - I can't
> tell.

It shouldn't.  The DLLs are in memory, so any subsequent invocation of
bash will load the cached versions (Windows does that automatically).

> Hint: Don't start bash so often. Create fewer processes, but if you
> must, see if you gain by using ash explicitely instead of bash.
>
> To the gurus - is the following correct?
> `echo blub` starts one process, `echo blub | sed -e 's/b/x/g'`
> starts three: "echo", "sed", and "bash" to implement the pipe.

I'm far from a guru, but let me take a shot at answering this:

If you're talking about running those from bash, then "echo blub" doesn't
start *any* processes -- "echo" is a bash builtin.  If you're asking about
make, make will start /bin/sh to execute the "echo" command.

"echo blub | sed -e ..." will start 1 process from bash, and 2 from make
(the 1 extra process is "sed" -- no process is created for the pipe).

FYI, "BLAH=blub; echo ${BLAH//b/x}" will not spawn *any* processes when
run directly from bash.

> d) Beware of lazy evaluation.
> Look at this construct:
> CFLAGS=$(shell find . -type d -name include)
> Read "info make" on setting variables and find out about the
> difference between "=" and ":=". The above will run the find
> again for every single call to the compiler. Along with the
> issues about forking and reading directories and small files,
> this can make a difference of *ages*.
> Hint: See whether you can use less variables, use ":=" more often,
> etc. - and don't use "$(shell ...)" anyway, as stated in a).
> Rather, pre-compute makefiles with all the data hardcoded, using
> ":=".

That's sound advice.

> e) Reading lots of small files seems more expensive on Windoze.
> I don't know about your Makefiles, but traditionally, makefiles are
> spread across project directories (for build

Re: A new day, a new snapshot, more testing required on the road to 1.5.19

[Christopher Faylor]

On Thu, Sep 15, 2005 at 10:39:22AM -0400, Volker Quetschke wrote:
>>>$ ./loop.csh
>>>loop
>>>Thu Sep 15 00:28:01 2005
>>>(nothing, no output) .
>>>
>>>You will see in the windows task manager that cppumaker is doing something
>>>but then it will hang. cppumaker will vanish from task manager but a
>>>"zombie"
>>>perl will remain. This perl will not be mentioned in the ps output.
>>>
>>>If you CRTL-Z the script and start ps you will still see the cppumaker
>>>process.
>>
>>
>>I got this working after downloading msv[pr]71.dll, but I just
>>repeatedly get this error:
>>
>>  Thu Sep 15 10:01:48 EDT 2005
>>  j:\tmp\solver\cppumaker.exe : init registries failed, check your 
>>  registry files.
>
>I forgot to mention that you have to adjust the path in loop.csh:
>
>./guw.pl cppumaker -Gc -L -BUCR -O. \
>/solver/680/wntmsci10.pro/bin/types.rdb
>
>>without a hang.  Is there something I should be setting up in the registry?
>
>I got it to run without the "init registries failed, check your registry
>files" problem on a computer that has never seen an OOo environment.

Bingo.  That hangs for me.  First try.  I'll track this down.  Thanks.

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: Cygwin build system SOOOO SLOOOWWWW ???

[Christopher Faylor]

On Thu, Sep 15, 2005 at 04:21:28PM +0200, Jan Schormann wrote:
>c) /bin/sh is now bash, which is now dynamically linked.
>Up until a few months ago, /bin/sh has been "ash", a smaller, but
>less powerfull shell. This has been replaced by bash, to reduce the
>traffic of repeated questions along the lines of "why does my shell
>act different than on linux" (where /bin/sh is bash on most
>distributions).
>
>If I understood the traffic on this list correctly, bash is now
>dynamically linked, which might have an impact on starting it - I can't
>tell.  Hint: Don't start bash so often.  Create fewer processes, but if
>you must, see if you gain by using ash explicitely instead of bash.

I'm not sure what you're getting at here.  bash hasn't changed.  ash
used DLLs, just like bash, but not so many of them.  And, in performance
tests, the difference between bash and ash was not that great.

>To the gurus - is the following correct?
>`echo blub` starts one process, `echo blub | sed -e 's/b/x/g'`
>starts three: "echo", "sed", and "bash" to implement the pipe.

I'm sure I will be one of 47 replies but 'echo blub' does not start any
process since 'echo' is a builtin.  AFAICT, 'echo blub | sed' starts one
process -- the sed process.  If you use a non-builtin on the left side
then two processes would be started.  This is one place where bash is
probably a win over ash.

>d) Beware of lazy evaluation.
>Look at this construct:
>CFLAGS=$(shell find . -type d -name include)

>Read "info make" on setting variables and find out about the difference
>between "=" and ":=".  The above will run the find again for every
>single call to the compiler.  Along with the issues about forking and
>reading directories and small files, this can make a difference of
>*ages*.  Hint: See whether you can use less variables, use ":=" more
>often, etc.  - and don't use "$(shell ...)" anyway, as stated in a).
>Rather, pre-compute makefiles with all the data hardcoded, using ":=".

Good advice.

>e) Reading lots of small files seems more expensive on Windoze.

I don't know if this is true or not.  Windows seems to do a good job
caching files but Cygwin does have a lot of extra overhead for every
file open so it may not matter how well Windows caches.

I've mentioned this many times before (and suspect that someone else is
frantically typing this in right now) but mounting directories which contain
executable files with the -X option makes things a little faster for cygwin:

  mount -f -b -X c:/cygwin/bin /bin
  mount -f -b -X c:/cygwin/bin /usr/bin
  mount -f -b -X c:/cygwin/sbin /sbin
  mount -f -b -X c:/cygwin/usr/sbin /usr/sbin
  mount -f -b -X c:/cygwin/usr/local/bin /usr/local/bin

This should be especially effective if you are accessing files over a remote
share.  OTOH, if you really want speed, you shouldn't be accessing a remote
share at all.

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/

Sould . (current dir) be in the PATH

[Morten Kjarulff]

Hi,

I just discovered that . (current directory) is in my PATH. I installed
cygwin on my new laptop some weeks ago. I don't think . was in my PATH on
my old PC. First I thought it came from my windows PATH, but it does not.

Is . normally in the PATH (it was not on a few solaris systems I just
checked, but that does not prove anything).

It is even twice in my PATH, as the last entry, and just after
/cygdrive/c/Infoprint.

/Morten

D:\mkj\bin>type cygwin.bat
@rem 2004-Dec-10 09:36:01 MKJ Based on cygwin.bat from installation

@rem Make sure we are in a new windows shell
@if X%BEENHERE% == XBEENHERE goto :BEENHERE
@%COMSPEC% /c set BEENHERE=BEENHERE ^& %0 %*
@exit /b %ERRORLEVEL%
:BEENHERE
@set BEENHERE=

@rem Where is CYGWIN installed
@set MYCYGWINROOT=D:\cygwin

@rem Set HOME
@set HOME=%MKJPATH%\mkj

@rem Start up command
@set MYCYGWINARG=
@if not X%1 == X (
  set MYCYGWINARG=-c "eval \"$MYCYGWINCMD\""
  set MYCYGWINCMD=%*
)

@rem Set options
@set CYGWIN=
@rem Ctrl-C does not perculate to cmd.exe if 'tty' is set
@rem X2 traps if 'tty' is set
@rem @set CYGWIN=tty

@rem Pretent we are CHERE, to avoid changing to HOME dir
@set CHERE_INVOKING=Y

@rem Now go
@%MYCYGWINROOT%\bin\bash -l %MYCYGWINARG%

D:\mkj\bin>set path
Path=C:\Program Files\Microsoft Visual Studio .NET
2003\Common7\IDE;C:\Program F
iles\Microsoft Visual Studio .NET 2003\VC7\BIN;C:\Program Files\Microsoft
Visual
 Studio .NET 2003\Common7\Tools;C:\Program Files\Microsoft Visual Studio
.NET 20
03\Common7\Tools\bin\prerelease;C:\Program Files\Microsoft Visual Studio
.NET 20
03\Common7\Tools\bin;C:\Program Files\Microsoft Visual Studio .NET
2003\SDK\v1.1
\bin;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\Program
Files\IBM\WebSphere
 MQ\Java\lib;C:\Program Files\CA\Dcs\DMScripting\;C:\Program
Files\CA\DCS\CAWIN\
;C:\PROGRAM
FILES\THINKPAD\UTILITIES;C:\WINDOWS\system32;C:\WINDOWS;C:\Merant\DI
MENS~1\8.0\PROG;C:\WINDOWS\System32\Wbem;C:\Program Files\IBM\Infoprint
Select;C
:\Utilities;C:\Notes;C:\Program Files\XLView\;C:\lotus\compnent\;C:\Program
File
s\IBM\Personal Communications\;C:\Program Files\IBM\Trace
Facility\;C:\WINDOWS\D
ownloaded Program Files;C:\Program Files\Intel\Wireless\Bin\;C:\Program
Files\AT
I Technologies\ATI Control Panel;C:\Program Files\CA\Unicenter Software
Delivery
\BIN;C:\CA_APPSW;C:\Program Files\CA\SharedComponents\CAM\bin;C:\Program
Files\H
ost Integration Server\system;C:\Program Files\Microsoft SQL
Server\80\Tools\BIN
N;C:\Program Files\IBM\WebSphere MQ\bin;C:\Program Files\IBM\WebSphere
MQ\tools\
c\samples\bin;C:\Program
Files\WinZip;C:\Infoprint;;d:\mkj\bin;d:\mkj\xmkj;d:\mk
j\x;d:\mkj\regina;
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH

D:\mkj\bin>.\cygwin.bat

[EMAIL PROTECTED] ~/bin
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program
Files/Microsoft
Visual Studio .NET 2003/Common7/IDE:/cygdrive/c/Program Files/Microsoft
Visual S
tudio .NET 2003/VC7/BIN:/cygdrive/c/Program Files/Microsoft Visual Studio
.NET 2
003/Common7/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio .NET
2003/Co
mmon7/Tools/bin/prerelease:/cygdrive/c/Program Files/Microsoft Visual
Studio .NE
T 2003/Common7/Tools/bin:/cygdrive/c/Program Files/Microsoft Visual Studio
.NET
2003/SDK/v1.1/bin:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v1.1.4322:/cygdriv
e/c/Program Files/IBM/WebSphere MQ/Java/lib:/cygdrive/c/Program
Files/CA/Dcs/DMS
cripting/:/cygdrive/c/Program Files/CA/DCS/CAWIN/:/cygdrive/c/PROGRAM
FILES/THIN
KPAD/UTILITIES:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/Mera
nt/DIMENS~1/8.0/PROG:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program
Files
/IBM/Infoprint
Select:/cygdrive/c/Utilities:/cygdrive/c/Notes:/cygdrive/c/Progra
m Files/XLView/:/cygdrive/c/lotus/compnent/:/cygdrive/c/Program
Files/IBM/Person
al Communications/:/cygdrive/c/Program Files/IBM/Trace
Facility/:/cygdrive/c/WIN
DOWS/Downloaded Program Files:/cygdrive/c/Program
Files/Intel/Wireless/Bin/:/cyg
drive/c/Program Files/ATI Technologies/ATI Control
Panel:/cygdrive/c/Program Fil
es/CA/Unicenter Software
Delivery/BIN:/cygdrive/c/CA_APPSW:/cygdrive/c/Program F
iles/CA/SharedComponents/CAM/bin:/cygdrive/c/Program Files/Host Integration
Serv
er/system:/cygdrive/c/Program Files/Microsoft SQL
Server/80/Tools/BINN:/cygdrive
/c/Program Files/IBM/WebSphere MQ/bin:/cygdrive/c/Program
Files/IBM/WebSphere MQ
/tools/c/samples/bin:/cygdrive/c/Program
Files/WinZip:/cygdrive/c/Infoprint:.:/c
ygdrive/d/mkj/bin:/cygdrive/d/mkj/xmkj:/cygdrive/d/mkj/x:/cygdrive/d/mkj/regina:
.

[EMAIL PROTECTED] ~/bin
$ cygcheck -s -v -r > cygcheck.out

[EMAIL PROTECTED] ~/bin
$



(See attached file: cygcheck.out)

cygcheck.out
Description: Binary data
--
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/

eval function not working anymore !?

[Yann Dubost]

Hello,

 I have been using cygwin for several years now and I have several scripts
tant do not work anymore since I installed the latest release of cygwin
(doxnloaded last week).
The reason is the eval function that I use quite a lot in such ways as :

DOMAINE_LISTE="DOM1 DOM2 DOM3"
DOM1_MODULES='D1_M1 D1_M2"
DOM2_MODULES="D2_M1 D2_M2"

for domain in $DOMAINE_LISTE
do
   eval MODULES=$"${domain}_MODULES"
   ...
done

Before it was working fine, but now echo $MODULES returns "DOM1_MODULES" or
"DOM2_MODULES" instead of "D1_M1 D1_M2" "D2_M1 D2_M2"

Have you experience such a change ? 
Do you have an idea why ?
How can I work around this problem (another function to use ?)

Regards,

Yann.


This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient,  you are not authorized 
to read, print, retain, copy, disseminate,  distribute, or use this message or 
any part thereof. If you receive this  message in error, please notify the 
sender immediately and delete all  copies of this message.


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

problem with getppid()

[Eduardo Chappa]

Hello,

  I have a problem runing the following program "test.c"

--
#include 
#include 
#include 

main()
{
  int p;

  if((p = getppid()) == 1)
printf("My parent is bad, ppid=%d\n", p);
  else
printf("My parent is good, ppid=%d\n", p);

  exit(0);
}


I build the program with the command

gcc -g -o test test.c

The problem is the following. When I execute the program in the command 
line


./test

I get the output: "My parent is good", but if I execute the same program 
under gdb


gdb ./test
(gdb) run

The output is "My parent is bad". I believe this is a bug in Cygwin's 
implementation of getppid().


Could someone please confirm this. Hopefully it is easy to fix.

Thank you.

--
Eduardo
http://www.math.washington.edu/~chappa/pine/

--
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 system SOOOO SLOOOWWWW ???

[Eric Blake]

> we've been struggling with speeding up our build process, too, so I'd
> like to share some ideas - yet I'm not so certain whether you'll learn
> from me or I'll learn from you: Hopefully both.

Thanks for a nice email, with quite a bit of useful and accurate info!

> - "strace" - though I haven't ever used it, but from what I know
>   this will definitely give you an answer - maybe two much of it ;-)

Yes, strace will tell you everything that cygwin is doing under
the hood, but it slows down normal execution and is not always
easy to parse to see what the time-killers are.

> 
> > 2) Has anyone else experienced speed problems with Cygwin?  Has
> > anybody else felt that Cygwin has gotten slower over the last
> > year or so?  Are there any guidelines or "tricks" for getting
> > Cygwin to run faster? 

Actually, I haven't noticed any slowdowns, and cgf has been
adding things to snapshots that try to speed up some cases.

> 
> a) Forking is more expensive in Windoze.
> On Unix, especially in make environments, you'll often start new
> processes as you're going - and often you'll not even notice. Google
> for "bash tricks" on how to fork less often.
> Hint: Don't use "sed" in `backticks` just for simple string
> replacements.
> Much of this can be done in make or bash directly.
> Look at the changes you made - maybe you thought it's more elegant?

That is true.  CVS libtool is gaining quite a bit of speed by deliberately
using bash builtins in place of fork()/exec() sequences.

> c) /bin/sh is now bash, which is now dynamically linked.
> Up until a few months ago, /bin/sh has been "ash", a smaller, but
> less powerfull shell. This has been replaced by bash, to reduce the
> traffic of repeated questions along the lines of "why does my shell
> act different than on linux" (where /bin/sh is bash on most
> distributions).
> If I understood the traffic on this list correctly, bash is now
> dynamically
> linked, which might have an impact on starting it - I can't tell.

It shouldn't have much impact - the reason we made the switch
from ash to bash is because no one could produce a test case
where bash was significantly slower.

> Hint: Don't start bash so often. Create fewer processes, but if you
> must, see if you gain by using ash explicitely instead of bash.
> 
> To the gurus - is the following correct?
> `echo blub` starts one process, `echo blub | sed -e 's/b/x/g'`
> starts three: "echo", "sed", and "bash" to implement the pipe.

Not quite - echo is a bash builtin, so it is bash and not echo.  But
you are right that it is 1 fork vs. 3 forks and 1 exec.

Here's where strace can be handy:
strace bash -c 'your command here' | grep '^Program name'
will show you how many forks and execs took place (execs
reuse a pid, forks create a new one).

> 
> d) Beware of lazy evaluation.
> Look at this construct:
> CFLAGS=$(shell find . -type d -name include)
> Read "info make" on setting variables and find out about the
> difference between "=" and ":=". The above will run the find
> again for every single call to the compiler. Along with the
> issues about forking and reading directories and small files,
> this can make a difference of *ages*.
> Hint: See whether you can use less variables, use ":=" more often,
> etc. - and don't use "$(shell ...)" anyway, as stated in a).
> Rather, pre-compute makefiles with all the data hardcoded, using
> ":=".

Definately true.  There are efficient ways of using make, and
there are slick constructs, and the two don't always overlap.

> 
> e) Reading lots of small files seems more expensive on Windoze.
> I don't know about your Makefiles, but traditionally, makefiles are
> spread across project directories (for build hierarchies), and
> makedepend
> creates even more of that. For one of our applications, I roughly
> calculated that make needs to open, read, and parse well over a
> thousand files (not counting the source or objects or any such thing,
> just the makefiles), just for telling you that all the targets are
> up to date.

Building monolithic makefiles at the top level instead of
recursing into subdirectory makes can speed up builds,
as well as give make better dependency information.
Google for 'recursive make considered harmful'.

--
Eric Blake



--
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: help on socket connexion

[znort]

Hello,

Ok, part of code...

If I run a client test (loop of 60 connection) to connect to the
server, all the fork/connection are ok...
but sometimes all the fork still "hang" in the process list even if I
stop the client


(sorry but the code is "as is")

thanx for your help




static int su=0;
static int dlog=0;
static HANDLE hlib;


sigjmp_buf context;


#define SET_BLOCKING(s)   set_blocking(s, XTRUE)
#define SET_NONBLOCKING(s)set_blocking(s, XFALSE)


static int sys_lock(int fd)
{
#if defined(F_SETLK)
  struct flock lockparam;

  lockparam.l_type = F_WRLCK;
  lockparam.l_whence = SEEK_SET;
  lockparam.l_start = 0;
  lockparam.l_len = 0;/* whole file */

  return fcntl(fd, F_SETLK, &lockparam);
#elif defined(HAVE_FLOCK)
  return flock(fd, LOCK_EX|LOCK_NB);
#elif defined(HAVE_LOCKF)
  return lockf(fd, F_TLOCK, 0);
#else
# error "No supported lock method..."
#endif
}




/**
*
*/ 
static int set_blocking(int sck, XBOOL flg)
{
  int f;
  
  f = fcntl(sck, F_GETFL, 0);
  
  if (f==-1)
return -1;

  if (flg==XFALSE)
return fcntl(sck, F_SETFL, f | O_NONBLOCK);
  else
return fcntl(sck, F_SETFL, f & (~O_NONBLOCK));
}




/*
*
*/
static void sigpipe(int s)
{
  log_killfile();
  printf("SIGPIPE\n");
  exit(0);
}


/*
*
*/
static void sigint(int s)
{
  log_killfile();
  printf("SIGINT\n");
  exit(0);
}



/*
*
*/
static void resume()
{
  printf("SIGSEGV\n");
  SET_CMD(pTmp, "signal 11");
  siglongjmp(context, 6);
}






/*
*
*/
static void sigchld(int n)
{
  int pid;

#ifdef CYGWIN
  pid = wait3(NULL, WNOHANG,NULL);

  if (pid>0) 
LP("sig-xsa", "child %d stops with signal %d", pid, n);

#else  
  while(1)
  {
pid = wait3(NULL, WNOHANG,NULL);

if (pid>0) 
  LP("sig-xsa", "child %d stops with signal %d", pid, n);
else
  break;  
  }
  

  signal(SIGCHLD,sigchld);
#endif  
}








/*
*/
static int init_nw(char *address, int port, SA_IN *servaddr)
{
  struct hostent *inf;
  int f_on=1;
  int s;
  
  s = socket(AF_INET, SOCK_STREAM, 0);

  if (s<0)   
return 0;

  /* evite time-out sur certain OS comme BSD */
  setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (void *) &f_on, sizeof(int));
  setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, (void *) &f_on, sizeof(int));

  _BZERO(servaddr, SA_IN);
  servaddr->sin_family = AF_INET;
  servaddr->sin_port = htons((unsigned short)port);

  if (address==NULL || strlen(address)==0)
servaddr->sin_addr.s_addr = htonl(INADDR_ANY);
  else
servaddr->sin_addr.s_addr = inet_addr(address); 

  /* pas une "dotted", recherche sa DNS */
  if (servaddr->sin_addr.s_addr==INADDR_NONE)
  {
inf = gethostbyname(address);

/*  impossible de trouver la dotted, marre... */
if (inf==NULL)
  return 0;

memcpy( &servaddr->sin_addr.s_addr, inf->h_addr, inf->h_length );
  }

  return s;
}






/**
*/
static void set_sigsev()
{
  sigset_t nset, oset;

  sigemptyset (&nset);
  sigaddset(&nset, SIGSEGV);
  sigprocmask (SIG_UNBLOCK, &nset, &oset);
  signal(SIGSEGV, resume);
}







static int xsa_running1( int cnt)
{
  struct timeval tv;
  fd_set readfds, rset;
  int rd, nb, ret;
  char ok[10];

  SET_NONBLOCKING(cnt);
 
  /* wait and see... */
  while (1)
  {
tv.tv_sec = 12;
tv.tv_usec = 0;
  
FD_ZERO(&rset);
FD_SET(cnt, &rset);
 
//readfds = rset;
rd = select(FD_SETSIZE, &rset, NULL, NULL, &tv);
   
if (rd!=0)
{
  if (FD_ISSET(cnt ,&rset))
  {
nb = recv(cnt, ok, 5, 0);
  
if (nb<=0)
{
  puts("");
  return 1;
}  
ok[nb]=0;  
printf(">>>%d%s", nb, ok);
  }
  else
return 1;  
}
else
{
  puts("wait");  
  fflush(stdout);
}  
  }
}
   







/*
*
*/
int main(int argc, char *argv[]) 
{
  int sd, r, d=0, cnt, z;
  XSA *x;
  SA_IN servaddr;
  int si=SA_CHUNK_DATA;
  fd_set readfds, rmask;
  struct timeval tv;
  socklen_t ln=sizeof(int);
  int rf, c=0, f=0;
  char *psz, path_config[512], tmp[1024];
  xstr val=NULL, val1=NULL;
  S_CFG cfg;
  int fd;
  char version[64];
  struct sockaddr_in adresse;
  int taille=sizeof adresse;  
 
  /* creation socket */
  sd = init_nw("", 5600, &servaddr);

  /* TCP Window size */
  setsockopt(sd, SOL_SOCKET, SO_SNDBUF, (char *) &si, sizeof(int));
  getsockopt(sd, SOL_SOCKET, SO_SNDBUF, &si, &ln);
  setsockopt(sd, SOL_SOCKET, SO_RCVBUF, (char *) &si, sizeof(int));

  if (SET_BLOCKING(sd)<0)
  {
log_puts("xsa", "O_NONBLOCK failed"); 
exit(500);
  }

  /* assigne adresse+port */
  if ( bind(sd, (SA *) &servaddr, sizeof(servaddr))==-1 )
  {
log_puts("xsa", "bind error...");
exit(501);
  }


  /* socket passe en incoming... */
  r = listen( sd, 5);


  while(1)
  {
cnt = accept(sd, &adresse, &taille);

if (cnt<0)
{
  if (errno != EINTR) 
  {
perror("accept");
close(sd);
exit(EXIT_FAILURE);
  }
 }
   
 rf = fork();

 if (rf==0)
 {
  

Re: problem with getppid()

[Corinna Vinschen]

On Sep 15 08:14, Eduardo Chappa wrote:
> gdb ./test
> (gdb) run
> 
> The output is "My parent is bad". I believe this is a bug in Cygwin's 
> implementation of getppid().

No, it's not a bug.  GDB starts the inferior process using the standard
Windows mechanisms since it should be useful also for native debugging.
When the inferior process is not started by Cygwin's own fork/exec
process, the child process doesn't know anything about its parent process,
at least not on Windows 9x.  There's a way to retrieve the native parent
PID by using NtQueryInformationProcess on NT, but it doesn't seem very
useful to get this information.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT 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: help on socket connexion

[znort]

Hello again;

In fact it seems the server "store" the number of descriptor from
select() even if the client disconnect... and after the limit of 64 it
fails (normal as I can read)

So, How can I do to "purge" the descriptor unused into the server ???

thanx for your help
:)

--
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: testers needed prior to 1.5.19 release

[Aaron Humphrey]

On 9/14/05, Christopher Faylor wrote:
> This will be fixed in the upcoming snapshot.  Look for the comment:

> * spawn.cc (av::fixup): Guard against problems reading an executable
> which does not match Microsoft's documentation about PE format.

> in the ChangeLog.  Once that shows up the snapshot will have the fix.

I just now encountered a very similar problem with "Argument list too
long"...with
a backgammon.exe(from bsd-games)compiled with cygwin gcc 3.3.1.  While
recompiling with gcc 3.4.4 produced a version that worked with older snapshots,
the new snapshot allows the older copy to work as well.


--
--Alfvaen (Web page: http://www.telusplanet.net/public/alfvaen/ )
Current Song--Cutting Crew:One For The Mockingbird
Current Book--Amy Tan:The Kitchen God's Wife
If I were perfect for you, wouldn't you tire of me?  --A Little Night
Music, "Soon"

--
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: eval function not working anymore !?

[Eric Blake]

> 
> Hello,
> 
>  I have been using cygwin for several years now and I have several scripts
> tant do not work anymore since I installed the latest release of cygwin
> (doxnloaded last week).
> The reason is the eval function that I use quite a lot in such ways as :

eval is not a function, but a builtin.

> 
> DOMAINE_LISTE="DOM1 DOM2 DOM3"
> DOM1_MODULES='D1_M1 D1_M2"

Well, I hope that was a copy-n-pasto, because otherwise it
would never work with mismatched quotes.

> DOM2_MODULES="D2_M1 D2_M2"
> 
> for domain in $DOMAINE_LISTE
> do
>eval MODULES=$"${domain}_MODULES"
>...
> done
> 
> Before it was working fine, but now echo $MODULES returns "DOM1_MODULES" or
> "DOM2_MODULES" instead of "D1_M1 D1_M2" "D2_M1 D2_M2"
> 
> Have you experience such a change ? 
> Do you have an idea why ?

Yes - sh is now bash, and bash has a POSIX-allowed extension
where $"  " has special meaning for purposes of string translation
($" is undefined by POSIX, and unimplemented by ash, so you
were lucky before).

> How can I work around this problem (another function to use ?)

Option 1: Fix your shell script to use POSIX compliant expressions
(basically, $" is non-portable in the first level of evaluation, so
quote the $ so that the second level of evaluation will see the
desired $DOM1_MODULES).  Any of the following properly quotes
the leading $ (and there are other ways, too):
eval MODULES=\$"${domain}_MODULES"
eval MODULES="\$${domain}_MODULES"
eval MODULES='$'"${domain}"_MODULES

Option 2: Disable the bash extension in your script:
shopt -u extquote

--
Eric Blake
volunteer cygwin bash maintainer



--
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: help on socket connexion

[Brian Dessent]

znort wrote:

> Ok, part of code...
> 
> If I run a client test (loop of 60 connection) to connect to the
> server, all the fork/connection are ok...
> but sometimes all the fork still "hang" in the process list even if I
> stop the client
> 
> (sorry but the code is "as is")

How can this code possibly compile?   There are no #includes!  When
someone asks for a testcase, that means something that will compile and
run -- not a snippet of something.

Before you continue, make sure your code compiles with no warnings with
-Wall.  If it does not, then fix the warnings.  They usually indicate
that you've done something wrong.

In general you can in fact define FD_SETSIZE to a larger number if you
desire, but this must be done BEFORE the system headers are included, so
that it is already set when the FD_ macros are defined.

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: eval function not working anymore !?

[Eric Blake]

> Option 1: Fix your shell script to use POSIX compliant expressions
> (basically, $" is non-portable in the first level of evaluation, so
> quote the $ so that the second level of evaluation will see the
> desired $DOM1_MODULES).  Any of the following properly quotes
> the leading $ (and there are other ways, too):
> eval MODULES=\$"${domain}_MODULES"
> eval MODULES="\$${domain}_MODULES"
> eval MODULES='$'"${domain}"_MODULES
> 
> Option 2: Disable the bash extension in your script:
> shopt -u extquote

Correction - 'man bash' states that extquote only affects
$"" inside of ${}, not eval.  So you will have to use option 1.

--
Eric Blake



--
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: eval function not working anymore !?

[Igor Pechtchanski]

On Thu, 15 Sep 2005, Yann Dubost wrote:

> Hello,
>
>  I have been using cygwin for several years now and I have several scripts
> tant do not work anymore since I installed the latest release of cygwin
> (doxnloaded last week).
> The reason is the eval function that I use quite a lot in such ways as :
>
> DOMAINE_LISTE="DOM1 DOM2 DOM3"
> DOM1_MODULES='D1_M1 D1_M2"
> DOM2_MODULES="D2_M1 D2_M2"
>
> for domain in $DOMAINE_LISTE
> do
>eval MODULES=$"${domain}_MODULES"
>...
> done
>
> Before it was working fine, but now echo $MODULES returns "DOM1_MODULES" or
> "DOM2_MODULES" instead of "D1_M1 D1_M2" "D2_M1 D2_M2"
>
> Have you experience such a change ?
> Do you have an idea why ?
> How can I work around this problem (another function to use ?)

This is most likely due to the switch of /bin/sh from ash to bash.  But
you could fix this with something more portable, like

   eval "MODULES=\$${domain}_MODULES"

HTH,
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!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

--
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: Unison 2.9.20 and OpenSSH-4.1p1-2: hangs as server.

[Andrew Schulman]

> after just a few bytes of network traffic (far 
> less than the full 400kb), it hangs.  Runs of "ps -ef" confirm that the 
> unison-2.9.20 processes are still running on both machines, but there is 
> no network traffic, and no CPU usage.
> 
> Attempts to run Unison on directories with lots of changed files, such 
> that Unison has multiple connections running, crash at the same point 
> with uncaught exceptions or "broken pipe" errors instead of hanging.  (I 
> can reproduce those if they'd be useful, but they seemed just random and 
> cryptic, and they weren't consistent if I changed the files, so I didn't 
> save them.)

Brooks, I do remember seeing a lot of reports about 6 months or so
ago, that Unison was hanging.  My recollection is dim but I think it
had to do with some bad combination of versions of cygwin.dll and
Unison.  Are you using the latest cygwin.dll on your servers?

Invoking unison with -debug will provide a lot of output, which may or
may not be useful.  At least you can see what was the last thing
Unison was doing before it hung, and that may ring a bell somewhere.
Also, exceptions and broken pipes are obvious errors that may lead
more easily to a solution if you report the details.

On balance though, I recommend that you upgrade to a recent (or at
least more recent) version of Unison if you can.  2.9.20 is getting
pretty old now.  It's still provided in Cygwin in order to allow
maximum version compatibility with other hosts, but there are a ton of
bug fixes and many new features in later versions.

Several more recent versions of Unison are available in Cygwin.  On
FreeBSD I don't know, but even if you have to fetch and build a more
recent version yourself, this is usually easy as long as you have
OCaml installed.  Of course all of your hosts have to be running the
same version of Unison, since different versions won't talk to each
other; or with versions 2.13.x and later, only the first two version
numbers (e.g. 2.13) have to match.

Good luck,
Andrew.


--
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: problem with getppid()

[Eduardo Chappa]

*** Corinna Vinschen ([EMAIL PROTECTED]) wrote in the cygwin...:

:) > The output is "My parent is bad". I believe this is a bug in Cygwin's 
:) > implementation of getppid().
:) 
:) No, it's not a bug.  GDB starts the inferior process using the standard 
:) Windows mechanisms since it should be useful also for native debugging. 
:) When the inferior process is not started by Cygwin's own fork/exec 
:) process, the child process doesn't know anything about its parent 
:) process, at least not on Windows 9x.  There's a way to retrieve the 
:) native parent PID by using NtQueryInformationProcess on NT, but it 
:) doesn't seem very useful to get this information.

Dear Corinna,

  Thank you for your fast response. Now I understand the issue that is 
involved. I have had this problem runing Pine in Cygwin. I've tried this 
in Windows 2000 Pro and Windows XP Pro. The same issue is not present in 
Linux, where I get the "expected" behavior. The manual of getppid makes me 
believe that the correct behavior for getppid is to return gdb's pid in 
the "bad" behavior, and since it is documented that getppid is supported 
in Cygwin, I would expect it to behave that way.

  The problem I have is that when Pine gets ppid == 1 it exits, and this 
is checked after a timeout for a select() command, which makes it very 
hard to debug pine under gdb. It would be great if I did not have to 
modify the source code of Pine to get around this problem. I can work 
around this at this moment, but I'd rather not have to modify Pine to work 
around this.

  From your response it seems that you are not willing to "fix" this 
problem. If that is the case, simply confirm this, and I will understand, 
otherwise it would be great if this were corrected in a future release and 
I would appreciate this a lot.

  Thank you for your consideration!

-- 
Eduardo
http://www.math.washington.edu/~chappa/pine/

--
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: Documentation on functions

[Siegfried Heintze]

Is there "documentation on the documentation"?

In other words, is the process of submitting documentation documented? Does
one use the GNU texi or SGML docbook or some other format? I've been curious
about these tools for years but have never used them.

Are there any functions documented (and I just had the bad luck of picking
the only three that were not documented) or do they all need to be
documented? (Yikes! That could be a big job)!

Is it a simple matter of cutting and pasting from linux (e.g. fedora) man
pages or does one have to go to the source code and extract the copious
comments there and just reformat them into man pages?

Siegfried


--
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: problem with getppid()

[Christopher Faylor]

On Thu, Sep 15, 2005 at 09:18:10AM -0700, Eduardo Chappa wrote:
>The problem I have is that when Pine gets ppid == 1 it exits, and this
>is checked after a timeout for a select() command, which makes it very
>hard to debug pine under gdb.

If your program looked like this:

47 int ppid = getppid ();
48
49 some c statement;

You could:

  % gdb pine
  (gdb) b 49
  (gdb) continue
  .
  .
  .
  (gdb) set var ppid = whatever
  (gdb) continue

The above is just a suggestion and is not a 100% accurate representation
of what needs to be done, of course.

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: Documentation on functions

[Reid Thompson]

Siegfried Heintze wrote:
> Is there "documentation on the documentation"?
> 
> In other words, is the process of submitting documentation
> documented? Does one use the GNU texi or SGML docbook or some
> other format? I've been curious about these tools for years
> but have never used them.
> 
> Are there any functions documented (and I just had the bad
> luck of picking the only three that were not documented) or
> do they all need to be documented? (Yikes! That could be a big job)!
> 
> Is it a simple matter of cutting and pasting from linux (e.g.
> fedora) man pages or does one have to go to the source code
> and extract the copious comments there and just reformat them
> into man pages?
> 
> Siegfried

$ man -w
/usr/local/man:/usr/share/man:/usr/local/pgsql/man:/usr/X11R6/man:/usr/s
sl/man:/usr/man
WS-XP-4960: /home/rthompso> 
$ ls /usr/local/man/*
/usr/local/man/ja:
man1

/usr/local/man/man1:
ascii-xfr.1  cscope.1  evim.1   gvimdiff.1  lua.1
mplayer.1   ratpoison.1  rview.1  sclite.1   vimdiff.1   wterm.1
aterm.1  dig.1 ex.1 host.1  luac.1  mrxvt.1
rgview.1 rvim.1   script.1   vimtutor.1  xminicom.1
blackbox.1   elinks.1  fontforge.1  imlib-config.1  mencoder.1  namazu.1
rgvim.1  rvimdiff.1   sfddiff.1  w3m.1   xmms.1
bsetbg.1 ervim.1   gview.1  imlib_config.1  minicom.1
nslookup.1  rover.1  rvimtutor.1  view.1 w3mman.1xxd.1
bsetroot.1   eview.1   gvim.1   links2.1mknmz.1
osd_cat.1   runscript.1  sc_stats.1   vim.1  wmxmms.1

/usr/local/man/man3:
lwres.3lwres_conf_parse.3
lwres_gai_strerror.3lwres_gnbaresponse_render.3
lwres_addr_parse.3 lwres_conf_print.3
lwres_getaddrinfo.3 lwres_herror.3
lwres_buffer.3 lwres_config.3
lwres_getaddrsbyname.3  lwres_hstrerror.3
lwres_buffer_add.3 lwres_context.3
lwres_gethostbyaddr.3   lwres_inetntop.3
lwres_buffer_back.3lwres_context_allocmem.3
lwres_gethostbyaddr_r.3 lwres_lwpacket_parseheader.3
lwres_buffer_clear.3   lwres_context_create.3
lwres_gethostbyname.3   lwres_lwpacket_renderheader.3
lwres_buffer_first.3   lwres_context_destroy.3
lwres_gethostbyname2.3  lwres_net_ntop.3
lwres_buffer_forward.3 lwres_context_freemem.3
lwres_gethostbyname_r.3 lwres_noop.3
lwres_buffer_getmem.3  lwres_context_initserial.3
lwres_gethostent.3  lwres_nooprequest_free.3
lwres_buffer_getuint16.3   lwres_context_nextserial.3
lwres_gethostent_r.3lwres_nooprequest_parse.3
lwres_buffer_getuint32.3   lwres_context_sendrecv.3
lwres_getipnode.3   lwres_nooprequest_render.3
lwres_buffer_getuint8.3lwres_endhostent.3
lwres_getipnodebyaddr.3 lwres_noopresponse_free.3
lwres_buffer_init.3lwres_endhostent_r.3
lwres_getipnodebyname.3 lwres_noopresponse_parse.3
lwres_buffer_invalidate.3  lwres_freeaddrinfo.3
lwres_getnamebyaddr.3   lwres_noopresponse_render.3
lwres_buffer_putmem.3  lwres_freehostent.3
lwres_getnameinfo.3 lwres_packet.3
lwres_buffer_putuint16.3   lwres_gabn.3
lwres_getrrsetbyname.3  lwres_resutil.3
lwres_buffer_putuint32.3   lwres_gabnrequest_free.3 lwres_gnba.3
lwres_sethostent.3
lwres_buffer_putuint8.3lwres_gabnrequest_parse.3
lwres_gnbarequest_free.3lwres_sethostent_r.3
lwres_buffer_subtract.3lwres_gabnrequest_render.3
lwres_gnbarequest_parse.3   lwres_string_parse.3
lwres_conf_clear.3 lwres_gabnresponse_free.3
lwres_gnbarequest_render.3  xosd.3
lwres_conf_get.3   lwres_gabnresponse_parse.3
lwres_gnbaresponse_free.3
lwres_conf_init.3  lwres_gabnresponse_render.3
lwres_gnbaresponse_parse.3

/usr/local/man/man5:
elinks.conf.5  elinkskeys.5  named.conf.5  rndc.conf.5

/usr/local/man/man8:
dnssec-keygen.8lft.8 mtr.8  named-checkzone.8
named.conf.5  rndc-confgen.8
dnssec-signzone.8  lwresd.8  named-checkconf.8  named.8
nsupdate.8rndc.8
WS-XP-4960: /home/rthompso> 
$ ls /usr/share/man/*
/usr/share/man/bg:
man1  man5

/usr/share/man/cat1:
fltk-config.1  fluid.1

/usr/share/man/cat3:
fltk.3

/usr/share/man/cs:
man1  man5

/usr/share/man/da:
man1  man5

/usr/share/man/de:
man1  man5  man6

/usr/share/man/el:
man1  man5  man8

/usr/share/man/es:
man1  man5

/usr/share/man/fi:
man1  man5

/usr/share/man/fr:
man1  man5  man6

/usr/share/man/hr:
man1  man5

/usr/share/man/it:
man1  man5  man6  man8

/usr/share/man/ja:
man1  man5

/usr/share/man/ko:
man1  man5

/usr/share/man/man1:
GraphicsMagick++-config.1  djpeg.1head.1.gz
oggenc.1splitdiff.1.gz
GraphicsMagick-config.1dlltool.1  help.1
ogginfo.1   sprut.1
ImageMagick.1  do.1
help2man.1.gz  oka.1   ssh-add.1
Magick++-config.1  done.1 history.1
onsgmls.1.gzssh-agent.1
Magick-config.1doxygen.1.gz
hostid.1.

mount -X and FAQ (was RE: Cygwin build system SOOOO SLOOOWWWW ???)

[Williams, Gerald S \(Jerry\)]

Christopher Faylor wrote:
> I've mentioned this many times before (and suspect that
> someone else is frantically typing this in right now) but
> mounting directories which contain executable files with
> the -X option makes things a little faster for cygwin:
> 
>   mount -f -b -X c:/cygwin/bin /bin

Finally got around to trying that one, but it broke the
tkinfo (Tcl/Tk) script I use regularly. Some experimenting
revealed that I had to add the following to make it work:

mount -f -b -x "c:/cygwin/bin/wish84.exe" "/bin/wish84.exe"
mount -f -b -x "c:/cygwin/bin/wish84.exe" "/usr/bin/wish84.exe"

and presumably I'd also want:

mount -f -b -x "c:/cygwin/bin/tclsh84.exe" "/bin/tclsh84.exe"
mount -f -b -x "c:/cygwin/bin/tclsh84.exe" "/usr/bin/tclsh84.exe"

The FAQ (http://www.cygwin.com/faq/faq_3.html) mentions
using this idiom for strace and cygcheck, but not for
Tcl/Tk. Perhaps these should be noted as well?

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: Documentation on functions

[Eric Blake]

> Is there "documentation on the documentation"?
> 
> In other words, is the process of submitting documentation documented? Does
> one use the GNU texi or SGML docbook or some other format? I've been curious
> about these tools for years but have never used them.

A while ago (Feb 05, if you are trying to see the changes in
newlib CVS), I documented newlib's strftime (well, improved the
existing documentation) when I added all the remaining bits
required to become POSIX compliant.  I did this by checking the
newlib sources out of CVS, then edited newlib/libc/time/strftime.c
and other files, and submitted the patch to the newlib mailing
list, where it was accepted.  A while later, once a subsequent cygwin
documentation release was made, man strftime (as well as info
strftime) had my doc edits!

For newlib documentation, the documentation is embedded
inline in the C files, plus a couple of glue .tex files, which are then
processed during the newlib build by texinfo to create the
documentation.  I just followed the existing styles, so strftime.c
is an example you can use when adding documentation to
functions that have none.

I'm not sure about adding cygwin function documentation.

> 
> Are there any functions documented (and I just had the bad luck of picking
> the only three that were not documented) or do they all need to be
> documented? (Yikes! That could be a big job)!
> 
> Is it a simple matter of cutting and pasting from linux (e.g. fedora) man
> pages or does one have to go to the source code and extract the copious
> comments there and just reformat them into man pages?

Don't just steal documentation from fedora, as it is likely to be wrong.
But it can be a good starting point.  newlib is different from glibc, and
not all things work the same between the systems.  It takes effort
to document actual behavior.  Also, editing man pages directly is
useless, because the format is so archaic, and because man pages
are usually generated from an upstream format (like texinfo).

--
Eric Blake



--
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: problem with getppid()

[Eduardo Chappa]

*** Christopher Faylor ([EMAIL PROTECTED]) wrote...:

:) If your program looked like this:
:) [removed some sample code, etc]
:) 
:) The above is just a suggestion and is not a 100% accurate 
:) representation of what needs to be done, of course.

Right, if this was just my case I could do this (not nice, but could do 
it). In my case I need to modify the source code every time I build it, 
and since it is a modification to work around a problem in cygwin, I was 
hoping that cygwin could be modified so that it would do the right thing, 
as it normally does.

Thank you.

-- 
Eduardo
http://www.math.washington.edu/~chappa/pine/

--
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: problem with getppid()

[Corinna Vinschen]

On Sep 15 09:18, Eduardo Chappa wrote:
>   The problem I have is that when Pine gets ppid == 1 it exits [...]

That's a bug in pine.  It means, you can't run pine from cmd.exe, resp.
command.com.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT 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: problem with getppid()

[Christopher Faylor]

On Thu, Sep 15, 2005 at 09:54:01AM -0700, Eduardo Chappa wrote:
>*** Christopher Faylor ([EMAIL PROTECTED]) wrote...:
>
>:) If your program looked like this:
>:) [removed some sample code, etc]
>:) 
>:) The above is just a suggestion and is not a 100% accurate 
>:) representation of what needs to be done, of course.
>
>Right, if this was just my case I could do this (not nice, but could do 
>it). In my case I need to modify the source code every time I build it, 
>and since it is a modification to work around a problem in cygwin, I was 
>hoping that cygwin could be modified so that it would do the right thing, 
>as it normally does.

Btw, if you don't actually care about the ppid value being a real pid,
you could add something like this to the list of gdb commands:

  (gdb) command 1
  End with a line saying just "end"
  set var ppid = 1234
  continue
  end

so that ppid would be set automatically.

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: Sould . (current dir) be in the PATH

[Larry Hall]

At 11:10 AM 9/15/2005, you wrote:
>Hi,
>
>I just discovered that . (current directory) is in my PATH. I installed
>cygwin on my new laptop some weeks ago. I don't think . was in my PATH on
>my old PC. First I thought it came from my windows PATH, but it does not.
>
>Is . normally in the PATH (it was not on a few solaris systems I just
>checked, but that does not prove anything).
>
>It is even twice in my PATH, as the last entry, and just after
>/cygdrive/c/Infoprint.
>

'.' is typically not put in the path by default for security reasons.




--
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: problem with getppid()

[Eduardo Chappa]

*** Corinna Vinschen ([EMAIL PROTECTED]) wrote in the cygwin...:

:) On Sep 15 09:18, Eduardo Chappa wrote:
:) >   The problem I have is that when Pine gets ppid == 1 it exits [...]
:) 
:) That's a bug in pine.  It means, you can't run pine from cmd.exe, resp. 
:) command.com.

Corinna,

  I can run Pine in cmd.exe, I have no problem with that. Let me give you 
and idea of the code.

 res = select()

 if(res == 0){
if(getppid() == 1)
  "exit(0)";

continue doing its stuff;
 }

 This code runs perfectly in Linux, both in terminal and under gdb, and it 
runs very well in Cygwin, but as you point out it does not run under 
cmd.exe. It is not a problem that it does not run in the latter case 
because one can run it under cygwin on a bash shell, so the latter is not 
an issue that is specially troubling. The real issue is that I get an 
"exit(0)" under gdb. That's my real issue. That's what I'd like to solve.

  From what I read in an earlier message from you, it seems like there is 
a way to fix the problem I have, and if it is possible to fix it, I would 
be grateful if it was fixed. I suppose that even though you explained 
where the problem is, that you can appreciate that getppid is not behaving 
correctly in the situation I described before.

  Of course it may be important for someone to be able to run Pine in 
cmd.exe, but a good workaround to that exists. I do not have a good 
workaround, hence my request. I hope you appreciate my point and what I am 
requesting.

  Thank you,

-- 
Eduardo
http://www.math.washington.edu/~chappa/pine/

--
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: Sould . (current dir) be in the PATH

[J. David Boyd]

Larry Hall <[EMAIL PROTECTED]> writes:

> At 11:10 AM 9/15/2005, you wrote:
>>Hi,
>>
>>I just discovered that . (current directory) is in my PATH. I installed
>>cygwin on my new laptop some weeks ago. I don't think . was in my PATH on
>>my old PC. First I thought it came from my windows PATH, but it does not.
>>
>>Is . normally in the PATH (it was not on a few solaris systems I just
>>checked, but that does not prove anything).
>>
>>It is even twice in my PATH, as the last entry, and just after
>>/cygdrive/c/Infoprint.
>>
>
> '.' is typically not put in the path by default for security reasons.
>
>

But then again, this is Cygwin, and how many _other_ people are going to be on
this machine?  I have '.' in my path, as I like to keep different scripts that
apply to certain directories in the affected directory.

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: problem with getppid()

[Corinna Vinschen]

On Sep 15 10:08, Eduardo Chappa wrote:
> *** Corinna Vinschen ([EMAIL PROTECTED]) wrote in the cygwin...:
> 
> :) On Sep 15 09:18, Eduardo Chappa wrote:
> :) >   The problem I have is that when Pine gets ppid == 1 it exits [...]
> :) 
> :) That's a bug in pine.  It means, you can't run pine from cmd.exe, resp. 
> :) command.com.
> 
> Corinna,
> 
>   I can run Pine in cmd.exe, I have no problem with that. Let me give you 
> and idea of the code.
> 
>  res = select()
> 
>  if(res == 0){
> if(getppid() == 1)
>   "exit(0)";
> 
> continue doing its stuff;
>  }
> 
>  This code runs perfectly in Linux, both in terminal and under gdb, and it 
> runs very well in Cygwin, but as you point out it does not run under 
> cmd.exe. It is not a problem that it does not run in the latter case 
> because one can run it under cygwin on a bash shell, so the latter is not 
> an issue that is specially troubling. The real issue is that I get an 
> "exit(0)" under gdb. That's my real issue. That's what I'd like to solve.

Let me reitterate.  If your parent process is a native Windows process,
there's no parent PID available.  This is nothing new and Cygwin emits
the PPID 1 already since the last century.  While on Linux (or whatever)
this means that the parent is the init process, on Cygwin it means, you
don't have a Cygwin parent process.  Having no Cygwin parent process
means, you don't have a chance to communicate with the parent process
by means of POSIX system calls.

The bottom line of this is, if you want to port pine to Cygwin correctly,
you will have to change the above code to something along the lines of


if(res == 0){
#ifndef __CYGWIN__
  if(getppid() == 1)
"exit(0)";
#endif

  continue doing its stuff;
}


This minimal porting effort will have only positive results, pine
suddenly works fine from cmd/command and also you won't have problems
to debug it using GDB.  So it helps everybody.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT 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: Sould . (current dir) be in the PATH

[Tino.Engel]

Hi,

'.' is not in the PATH due to security reasons on most business setups.
I do not know if this is due to security against external threads or the
user himself...
But if you can handle it...
Otherwise you should overwrite it in your .bashrc or .rc.

Something like(!) PATH="`echo $PATH | sed 's/:\.:/:/'" should work...

Rg, Tino


 
Tino Engel (MP PDT CS CADF) tel.:   +49 89 234 28059 
Infineon Technologies AGmobile: +49 176 21137381 
Room:  Mch B3253 


-Original Message-
From: cygwin-owner AT cygwin DOTcom [mailto:cygwin-owner AT cygwin DOT
com] On Behalf Of Morten Kjarulff
Sent: Thursday, September 15, 2005 5:10 PM
To: cygwin AT cygwin.com
Subject: Sould . (current dir) be in the PATH

Hi,

I just discovered that . (current directory) is in my PATH. I installed
cygwin on my new laptop some weeks ago. I don't think . was in my PATH
on
my old PC. First I thought it came from my windows PATH, but it does
not.

Is . normally in the PATH (it was not on a few solaris systems I just
checked, but that does not prove anything).

It is even twice in my PATH, as the last entry, and just after
/cygdrive/c/Infoprint.

/Morten

D:\mkj\bin>type cygwin.bat
@rem 2004-Dec-10 09:36:01 MKJ Based on cygwin.bat from installation

@rem Make sure we are in a new windows shell
@if X%BEENHERE% == XBEENHERE goto :BEENHERE
@%COMSPEC% /c set BEENHERE=BEENHERE ^& %0 %*
@exit /b %ERRORLEVEL%
:BEENHERE
@set BEENHERE=

@rem Where is CYGWIN installed
@set MYCYGWINROOT=D:\cygwin

@rem Set HOME
@set HOME=%MKJPATH%\mkj

@rem Start up command
@set MYCYGWINARG=
@if not X%1 == X (
  set MYCYGWINARG=-c "eval \"$MYCYGWINCMD\""
  set MYCYGWINCMD=%*
)

@rem Set options
@set CYGWIN=
@rem Ctrl-C does not perculate to cmd.exe if 'tty' is set
@rem X2 traps if 'tty' is set
@rem @set CYGWIN=tty

@rem Pretent we are CHERE, to avoid changing to HOME dir
@set CHERE_INVOKING=Y

@rem Now go
@%MYCYGWINROOT%\bin\bash -l %MYCYGWINARG%

D:\mkj\bin>set path
Path=C:\Program Files\Microsoft Visual Studio .NET
2003\Common7\IDE;C:\Program F
iles\Microsoft Visual Studio .NET 2003\VC7\BIN;C:\Program
Files\Microsoft
Visual
 Studio .NET 2003\Common7\Tools;C:\Program Files\Microsoft Visual Studio
.NET 20
03\Common7\Tools\bin\prerelease;C:\Program Files\Microsoft Visual Studio
.NET 20
03\Common7\Tools\bin;C:\Program Files\Microsoft Visual Studio .NET
2003\SDK\v1.1
\bin;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\Program
Files\IBM\WebSphere
 MQ\Java\lib;C:\Program Files\CA\Dcs\DMScripting\;C:\Program
Files\CA\DCS\CAWIN\
;C:\PROGRAM
FILES\THINKPAD\UTILITIES;C:\WINDOWS\system32;C:\WINDOWS;C:\Merant\DI
MENS~1\8.0\PROG;C:\WINDOWS\System32\Wbem;C:\Program Files\IBM\Infoprint
Select;C
:\Utilities;C:\Notes;C:\Program
Files\XLView\;C:\lotus\compnent\;C:\Program
File
s\IBM\Personal Communications\;C:\Program Files\IBM\Trace
Facility\;C:\WINDOWS\D
ownloaded Program Files;C:\Program Files\Intel\Wireless\Bin\;C:\Program
Files\AT
I Technologies\ATI Control Panel;C:\Program Files\CA\Unicenter Software
Delivery
\BIN;C:\CA_APPSW;C:\Program Files\CA\SharedComponents\CAM\bin;C:\Program
Files\H
ost Integration Server\system;C:\Program Files\Microsoft SQL
Server\80\Tools\BIN
N;C:\Program Files\IBM\WebSphere MQ\bin;C:\Program Files\IBM\WebSphere
MQ\tools\
c\samples\bin;C:\Program
Files\WinZip;C:\Infoprint;;d:\mkj\bin;d:\mkj\xmkj;d:\mk
j\x;d:\mkj\regina;
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH

D:\mkj\bin>.\cygwin.bat

[EMAIL PROTECTED] ~/bin
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program
Files/Microsoft
Visual Studio .NET 2003/Common7/IDE:/cygdrive/c/Program Files/Microsoft
Visual S
tudio .NET 2003/VC7/BIN:/cygdrive/c/Program Files/Microsoft Visual
Studio
.NET 2
003/Common7/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio .NET
2003/Co
mmon7/Tools/bin/prerelease:/cygdrive/c/Program Files/Microsoft Visual
Studio .NE
T 2003/Common7/Tools/bin:/cygdrive/c/Program Files/Microsoft Visual
Studio
.NET
2003/SDK/v1.1/bin:/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v1.1.4322:
/cygdriv
e/c/Program Files/IBM/WebSphere MQ/Java/lib:/cygdrive/c/Program
Files/CA/Dcs/DMS
cripting/:/cygdrive/c/Program Files/CA/DCS/CAWIN/:/cygdrive/c/PROGRAM
FILES/THIN
KPAD/UTILITIES:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdriv
e/c/Mera
nt/DIMENS~1/8.0/PROG:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Progr
am
Files
/IBM/Infoprint
Select:/cygdrive/c/Utilities:/cygdrive/c/Notes:/cygdrive/c/Progra
m Files/XLView/:/cygdrive/c/lotus/compnent/:/cygdrive/c/Program
Files/IBM/Person
al Communications/:/cygdrive/c/Program Files/IBM/Trace
Facility/:/cygdrive/c/WIN
DOWS/Downloaded Program Files:/cygdrive/c/Program
Files/Intel/Wireless/Bin/:/cyg
drive/c/Program Files/ATI Technologies/ATI Control
Panel:/cygdrive/c/Program Fil
es/CA/Unicenter Software
Delivery/BIN:/cygdrive/c/CA_APPSW:/cygdrive/c/Program F
iles/CA/SharedComponents/CAM/bin:/cygdrive/c/Program

RE: Sould . (current dir) be in the PATH

[Dave Korn]

Original Message
>From: [EMAIL PROTECTED]
>Sent: 15 September 2005 18:35

> Hi,
> 
> '.' is not in the PATH due to security reasons on most business setups.
> I do not know if this is due to security against external threads or the
> user himself...


  Both, kind of.

  Imagine what would happen if

1)  The root user has '.' in $PATH
2)  The root user wants to see what files are in /tmp, so issues the
commands
   cd /tmp
   ls
3)  Ten minutes earlier, some other user ran
   echo "rm -rf / &" >/tmp/ls ; chmod a+x /tmp/ls

  Not having '.' in your $PATH means that when you run ls, you always get
the real ls.  (Assuming you haven't given world write perms to /bin).

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: A new day, a new snapshot, more testing required on the road to 1.5.19

[Brian Ford]

On Wed, 14 Sep 2005, Christopher Faylor wrote:

> On Wed, Sep 14, 2005 at 03:41:06PM -0500, Brian Ford wrote:
> >Regression from 1.5.18.  It seems gethostbyname is not working
> >correctly from secondary threads:
>
> This should be fixed in the latest snapshot from 2005-Sep-14.

It is.  Thanks!

> Thanks for the test case and for providing everything that I asked for,
> Brian.

You're welcome.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...

--
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: Sould . (current dir) be in the PATH

[Eric Blake]

> At 11:10 AM 9/15/2005, you wrote:
> >Hi,
> >
> >I just discovered that . (current directory) is in my PATH. I installed
> >cygwin on my new laptop some weeks ago. I don't think . was in my PATH on
> >my old PC. First I thought it came from my windows PATH, but it does not.
> >
> >Is . normally in the PATH (it was not on a few solaris systems I just
> >checked, but that does not prove anything).

On Windows, . is always in your path (stupid, but true).

In POSIX, . is only in PATH if you put it there.  However, POSIX
states that a leading or trailing :, or doubled :: in the middle of
your PATH implies `.' on your PATH.  Furthermore, when cygwin
translates your Windows %PATH% into the POSIX PATH, it
treats ; as :.  There are several Windows programs that are
rather unfriendly in how they modify %PATH% on installation,
such that you are left with trailing or duplicate ;, which is why
you might be seeing . in your PATH even though you don't
remember putting it there.

> >
> >It is even twice in my PATH, as the last entry, and just after
> >/cygdrive/c/Infoprint.
> >
> 
> '.' is typically not put in the path by default for security reasons.

On the other hand, I like having it in my PATH (okay, so I'm asking
for problems security-wise), but ONLY when it is the LAST entry,
because it saves me two characters when typing configure instead
of ./configure (on the other hand, if I were truly lazy, I'd create
'alias conf=./configure' and have even less to type without having
to put . on my PATH).  The security problem is that if . appears
before absolute directories, then if you cd to a directory where
you have a program of the same name (think ls), you invoke ./ls
instead of the intended /bin/ls.  Classic trojan horse, if you
weren't the author of ./ls.

BTW, 'find -execdir' will complain and fail if . is in your PATH, so
choose your battles.

--
Eric Blake



--
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.18-1 Segfault on setup postinstall

[Andrew Comport]

Eric Blake wrote:


I left the install running overnightstill no progress...



Part of your problem is explained by this:


Not Found: sh



/etc/postinstall/00ash.sh tries to set up a working /bin/sh.  If that
fails, then everything else is suspect.



Upon inspection It is bash.exe (called within 00ash.sh) which crashes. I 
have created a strace for bash.exe which I have attached as a file.  I have 
been unable to decipher eactly where this crashes.


Please note that i have edited the file to replace my Firstname and Lastname 
to be Firstname and Lastname.




Apparently its not cygcheck that crashes but id.exe:

 3 [main] id 2792 handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
 18910 [main] id 2792 open_stackdumpfile: Dumping stack trace to 
id.exe.stackdu

mp
garbled output from `id' command - no uid= found



Figuring this out might help.  Can you run 'strace -o strace.out id'
and attach strace.out to your reply, to see if something obvious
in id.exe or cygwin1.dll is reading bad memory?  You may also
want to try reinstalling coreutils, in case id.exe is corrupt.

I have also checked my PATH  and set it to the basic PATHs of windows only 
so as to make sure no similar commands are on the path (which didnt help).



While not exactly wrong to change your PATH just before running
cygcheck, it is a bit counterintuitive since part of cygcheck's purpose
is to diagnose PATH problems in your current PATH.



I actually tried both ways. One with a minimal PATH and one with everything. 
The cygcheck output was the one without altering the full path.



Thanks for you help so far,

Andrew



strace.log
Description: Binary data
--
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: Unison 2.9.20 and OpenSSH-4.1p1-2: hangs as server.

[Brooks Moses]

Andrew Schulman wrote:

Brooks, I do remember seeing a lot of reports about 6 months or so
ago, that Unison was hanging.  My recollection is dim but I think it
had to do with some bad combination of versions of cygwin.dll and
Unison.  Are you using the latest cygwin.dll on your servers?


"uname -sr" returns "CYGWIN_NT-5.2 1.5.18(0.132/4/2)", which I believe 
means I'm running the latest version.


I also noticed that there was a new OpenSSH package out; I've upgraded 
to OpenSSH-4.2p1-1 on the server side, and found that this changed 
nothing with regards to this bug.



Invoking unison with -debug will provide a lot of output, which may or
may not be useful.  At least you can see what was the last thing
Unison was doing before it hung, and that may ring a bell somewhere.
Also, exceptions and broken pipes are obvious errors that may lead
more easily to a solution if you report the details.


True enough.  I've attached the text of unison -debug 'all' to this; I'm 
not sure if it's meaningful or not.


Here's what the broken pipe error looks like, meanwhile (note that I've 
snipped portions of this, noted with [... snip ...] blocks:


[Quoting from my terminal window]

brooks-laptop:~/temp> unison references-home
Contacting server...
[EMAIL PROTECTED]'s password:
Looking for changes
  Administrative_Stuff

[... snip a bunch ...]

  whitepapers/ME271_Combustion
  Waiting for changes from server
Reconciling changes

local  mindolluin
new file <-?-> new file   
journal_papers/ARFM2005_Dimotakis_Turbulent_Mixing.pdf  [] /
new file <-?-> new file   journal_papers/ARFM2005_Dimotakis_Turbulent_Mixing.pdf
new file >
journal_papers/ACM2005_Song_Stable_Non-Dissipative_Water.pdf  [f]

[... snip a bunch ...]

new file >
whitepapers/LKT-01-00_Meier_Towards_DNS_of_Multiphase.ps.gz  [f]

Proceed with propagating updates? []
No default command [type '?' for help]
Proceed with propagating updates? [] y
Propagating updates


UNISON started propagating changes at 11:30:37 on 15 Sep 2005
[CONFLICT] Skipping journal_papers/ARFM2005_Dimotakis_Turbulent_Mixing.pdf
[BGN] Copying journal_papers/ACM2005_Song_Stable_Non-Dissipative_Water.pdf
  from /disk2/brooks/reference-pdfs
  to //mindolluin//disk2/brooks/reference-pdfs

[... snip 19 more [BGN] blocks ...]

Uncaught exception File 
"/home/aschulma/usr/cygwin/unison2.9.20/unison2.9.20-2.9.20/.build/remote.ml
", line 483, characters 2-8: Assertion failed
Broken pipe


Incidentally, this points out a definite bug in Unison-2.9.20.  This 
exact output also occurs if I specify "-maxthreads 1" on the command 
line, indicating that it is ignoring that option and opening the default 
20 threads anyway.  (If I use the "-debug 'all'" option along with 
"-maxthreads 1", it does report "maxthreads = 1" in the list at the 
beginning, so it's parsing the option, just ignoring it.)


[Now back to quoting Andrew Schulman]

On balance though, I recommend that you upgrade to a recent (or at
least more recent) version of Unison if you can.  2.9.20 is getting
pretty old now.  It's still provided in Cygwin in order to allow
maximum version compatibility with other hosts, but there are a ton of
bug fixes and many new features in later versions.

Several more recent versions of Unison are available in Cygwin.  On
FreeBSD I don't know, but even if you have to fetch and build a more
recent version yourself, this is usually easy as long as you have
OCaml installed.  Of course all of your hosts have to be running the
same version of Unison, since different versions won't talk to each
other; or with versions 2.13.x and later, only the first two version
numbers (e.g. 2.13) have to match.


I'll give that a try next; I just wanted to get these errors confirmed 
and documented first.


Unfortunately, I don't have root on the remote server, so it may be a 
little difficult to upgrade, but I see that Cygwin does seem to allow 
having multiple versions of unison around -- many thanks to whomever was 
responsible for that!


Thanks again,
- Brooks



brooks-laptop:~/temp> unison a ssh://192.168.0.1/temp/a -debug 'all'
Preferences:
ui = graphic
server = false
prefsdocs = false
doc =
version = false
silent = false
dumbtty = true
testserver = false
rest = ssh://192.168.0.1/temp/a
rest = a
contactquietly = false
key =
label =
expert = false
reusewindows = false
height = 20
batch = false
auto = false
maxthreads = 20
backups = false
prefer =
force =
sortnewfirst = true
sortbysize = false
editor = emacs
merge2 =
merge =
diff = diff
verifyTransfers = false
statusdepth = 2
fastcheck = default
backupdir =
maxbackups = 2
rootsName =
root = ssh://192.168.0.1/temp/a
root = a
killserver = false
rsync = true
addversionno = false
servercmd =
rshargs =
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion =
pretendwin = false
times = true
group = false
owner = false
numericids = false
perms = 1023
ignorecase = true
timers = false
terse = false
logfile = /disk2/brooks/unison.log
log = tr

Re: Sould . (current dir) be in the PATH

[J. David Boyd]

"Dave Korn" <[EMAIL PROTECTED]> writes:

> Original Message
>>From: [EMAIL PROTECTED]
>>Sent: 15 September 2005 18:35
>
>> Hi,
>> 
>> '.' is not in the PATH due to security reasons on most business setups.
>> I do not know if this is due to security against external threads or the
>> user himself...
>
>
>   Both, kind of.
>
>   Imagine what would happen if
>
> 1)  The root user has '.' in $PATH
> 2)  The root user wants to see what files are in /tmp, so issues the
> commands
>cd /tmp
>ls
> 3)  Ten minutes earlier, some other user ran
>echo "rm -rf / &" >/tmp/ls ; chmod a+x /tmp/ls
>
>   Not having '.' in your $PATH means that when you run ls, you always get
> the real ls.  (Assuming you haven't given world write perms to /bin).
>

Sure, a totally valid point on Unix or Linux.  But on most cygwin installs
that I know of, there is only one user, and if that user (me, for instance),
did something that stupid, oh well...



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

[TITTTL] RE: Sould . (current dir) be in the PATH

[Dave Korn]

Original Message
>From: J. David Boyd
>Sent: 15 September 2005 19:59

> "Dave Korn" <[EMAIL PROTECTED]> writes:

  Dave gentle reminder:  http://cygwin.com/acronyms#PCYMTNQREAIYR

> Sure, a totally valid point on Unix or Linux.  But on most cygwin installs
> that I know of, there is only one user, and if that user (me, for
> instance), did something that stupid, oh well...

  Well.  It's not just directly multi-user systems that are vulnerable; for
example, there must be plenty of cgi scripts on webservers out there that
create files in /tmp with content from a user's request, and if the name can
be manipulated as well boom!

  But this is all OT now.  If you want to carry on discussing generalised
security stuff, let's http://cygwin.com/acronyms#TITTTL.
Bock-bock-b'gawk!



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/

Why does stat fail for some files?

[Mikael]

Hello, I'm doing homework and I'm having some problems with stat() failing. 
Consider the following C program:

#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 

static void scan_directory(const char *);

int
main(int argc, char **argv)
{
   if(argc == 1)
   {
  fprintf(stderr, "Usage: dirscan path\n");

  return EXIT_FAILURE;
   }

   scan_directory(argv[1]);

   return EXIT_SUCCESS;
}

static void
scan_directory(const char *path)
{
   DIR *directory = NULL;
   struct dirent *entry = NULL;
   struct stat statbuf;
   int return_value = 0;

   directory = opendir(path);

   if(!directory)
   {
  fprintf(stderr, "Directory %s could not be opened.\n", path);
  fprintf(stderr, "Reason: %s\n", strerror(errno));

  /* Don't exit program, we may have been called recursively and
 we want to scan what we can.*/
  return;
   }

   while((entry = readdir(directory)))
   {
  return_value = stat(entry->d_name, &statbuf);

  if(return_value)
 fprintf(stderr, "stat() failed for %s. Reason: %s\n",
   entry->d_name, strerror(errno));
  else
 printf("stat() called successfully on: %s\n", entry->d_name);
   }

   return_value = closedir(directory);

   assert(!return_value); /* closedir() returns 0 on success */
}

And this is what happens when I run it (first ls -al):
$ ls -al /c/cygwin/home/mikael/coding/cygwin/c++/read_directory/
total 773
drwxrwxrwx+  2 mikael None  0 Sep 15 16:36 ./
drwxrwxrwx+ 16 mikael None  0 May 20 22:53 ../
-rwxrwxrwx   1 mikael None273 Sep 15 16:36 Makefile*
-rwxrwxrwx   1 mikael None792 Aug 19  2004 read_directory.cpp*
-rwxr-xr-x   1 mikael None 604746 Sep 15 16:36 read_directory.exe*
-rw-r--r--   1 mikael None 129520 Sep 15 16:36 read_directory.o

$ ./dirscan.exe /c/cygwin/home/mikael/coding/cygwin/c++/read_directory/
stat() called successfully on: .
stat() called successfully on: ..
stat() called successfully on: Makefile
stat() failed for read_directory.cpp. Reason: No such file or directory
stat() failed for read_directory.exe. Reason: No such file or directory
stat() failed for read_directory.o. Reason: No such file or directory

Why is this happening? I'm attaching the C-file and a Makefile. Perform a "$ 
make dirscan2" if you want to build.

/ Mikael 


begin 666 Makefile.dat
M0T,@/2!G8V,-"D-&3$%'4R ]("U786QL("U7("UA;G-I("UP961A;G1I8R M
M9R M3S @+6,@+6\-"DQ$1DQ!1U,@/2 M;R D*$5814,I#0I%6$5#([EMAIL PROTECTED]&ER
M&4-"D]"2D5#5%,@/2!D:7)S8V%N+F\-"D]"2D5#5%,R([EMAIL PROTECTED]&ER
M("0H3$1&
M3$%'4RD-"@T*)2YO.B E+F,-"@DD*$-#*2 D*$-&3$%'4RD@)$ @)#P-"@T*
M8VQE86XZ#0H)<[EMAIL PROTECTED]@)"A/0DI%0U13*2 D*$]"2D5#5%,R*2 D*$5814,I
1("I^("HN2AA2 ]($Y53$P[#0H@("!S=')[EMAIL PROTECTED]&ER96YT("IE;G1R>2 ]($Y53$P[#0H@
M("!S=')U8W0@2 E2DI*0T*(" @>PT*
M(" @(" @2T^9%]N86UE+" Fhttp://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Why does stat fail for some files?

[Eric Blake]

> Hello, I'm doing homework and I'm having some problems with stat() failing. 

It's called homework for a reason, but here are some hints:

> Consider the following C program:
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #include 
> #include 
> #include 
> 
> static void scan_directory(const char *);
> 
> int
> main(int argc, char **argv)
> {
>if(argc == 1)
>{
>   fprintf(stderr, "Usage: dirscan path\n");
> 
>   return EXIT_FAILURE;
>}
> 
>scan_directory(argv[1]);
> 
>return EXIT_SUCCESS;
> }
> 
> static void
> scan_directory(const char *path)
> {
>DIR *directory = NULL;
>struct dirent *entry = NULL;
>struct stat statbuf;
>int return_value = 0;
> 
>directory = opendir(path);
> 
>if(!directory)
>{
>   fprintf(stderr, "Directory %s could not be opened.\n", path);

fprintf can clobber errno...

>   fprintf(stderr, "Reason: %s\n", strerror(errno));

so you may be printing the wrong reason.

> 
>   /* Don't exit program, we may have been called recursively and
>  we want to scan what we can.*/
>   return;
>}
> 
>while((entry = readdir(directory)))

You just ignored the possibility that readdir might set errno.

>{
>   return_value = stat(entry->d_name, &statbuf);

Hmm - think relative vs. absolute pathname, then consider where
you invoked your command.

> 
>   if(return_value)
>  fprintf(stderr, "stat() failed for %s. Reason: %s\n",
>entry->d_name, strerror(errno));
>   else
>  printf("stat() called successfully on: %s\n", entry->d_name);
>}
> 
>return_value = closedir(directory);
> 
>assert(!return_value); /* closedir() returns 0 on success */
> }
> 
> And this is what happens when I run it (first ls -al):
> $ ls -al /c/cygwin/home/mikael/coding/cygwin/c++/read_directory/
> total 773
> drwxrwxrwx+  2 mikael None  0 Sep 15 16:36 ./
> drwxrwxrwx+ 16 mikael None  0 May 20 22:53 ../
> -rwxrwxrwx   1 mikael None273 Sep 15 16:36 Makefile*
> -rwxrwxrwx   1 mikael None792 Aug 19  2004 read_directory.cpp*
> -rwxr-xr-x   1 mikael None 604746 Sep 15 16:36 read_directory.exe*
> -rw-r--r--   1 mikael None 129520 Sep 15 16:36 read_directory.o
> 
> $ ./dirscan.exe /c/cygwin/home/mikael/coding/cygwin/c++/read_directory/
> stat() called successfully on: .
> stat() called successfully on: ..
> stat() called successfully on: Makefile
> stat() failed for read_directory.cpp. Reason: No such file or directory
> stat() failed for read_directory.exe. Reason: No such file or directory
> stat() failed for read_directory.o. Reason: No such file or directory

As a side note, Windows has the annoying habit that when a file
is locked by another application, stat() won't get much information
about the file, but at least it won't fail.

--
Eric Blake



--
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: Unison 2.9.20 and OpenSSH-4.1p1-2: hangs as server. (Update)

[Brooks Moses]

An update

Andrew Schulman wrote:

On balance though, I recommend that you upgrade to a recent (or at
least more recent) version of Unison if you can.  2.9.20 is getting
pretty old now.  It's still provided in Cygwin in order to allow
maximum version compatibility with other hosts, but there are a ton of
bug fixes and many new features in later versions.

Several more recent versions of Unison are available in Cygwin.  On
FreeBSD I don't know, but even if you have to fetch and build a more
recent version yourself, this is usually easy as long as you have
OCaml installed.  Of course all of your hosts have to be running the
same version of Unison, since different versions won't talk to each
other; or with versions 2.13.x and later, only the first two version
numbers (e.g. 2.13) have to match.


I've now upgraded to Unison 2.17-1 on both the Desktop and the Laptop, 
and confirmed that "unison -version" produces "unison version 2.17.1" on 
both boxes.  Also, other output, such as the regeneration of databases, 
leads me to feel confident that it is actually running version 2.17, 
even though version 2.9.20 is still installed.  (For those following 
along, this required manually setting the unison.exe symlink in 
/etc/alternatives to point to the new version rather than the old version.)


In any case, the problems continue nearly identically with the new 
version.  I've attached the tail of the -debug 'all' output for the case 
of one file (which hangs).  The case with multiple files in a "real" 
directory is also nearly identical, though the exception has of course 
changed line numbers.  It's now:



Uncaught exception File "/home/aschulma/usr/cygwin/unison2.17/unison2.17-2.17.1/
.build/remote.ml", line 530, characters 2-8: Assertion failed


I hope that's of use; let me know if there's any other debugging info I 
can provide.


Thanks much,
- Brooks

P.S. In reference to the "-maxthreads 1" option bug I mentioned in 
version 2.9.20 -- this seems to be fixed in version 2.17, and works 
properly.  When I specify "-maxthreads 1" on the "real" directory, it 
now tries to send exactly one file at a time, and thus hangs.



[Now quoting tail of -debug 'all' output]

[remote_emit] Received write token (1)
[server: pred] ignore 'ARFM2004_Weinstein_Coating_Flows_preprint.pdf' = false
[server: remote_emit] Sending result (id: 10)
[server: remote_emit] send [updateArchive-res] 
'\132\149\166\190\000\000\0001\000\000...' 69 bytes
[generic] sending file
Growing heap to 480k bytes
[server: remote_emit] send [rsp] '\132\149\166\190\000\000\000\001\000\000...' 
21 bytes
[server: copy] tryCopyMovedFile: -> 
.#ARFM2004_Weinstein_Coating_Flows_preprint.pdf.54546f.unison.tm
p /(394fe90eb22d24739c8653518ea0ede6,)/
[server: xferhint] lookup: fp = (394fe90eb22d24739c8653518ea0ede6,)
Growing page table to 171 entries
[rsynctoken] flushing the token queue
[remote_emit] send [processTransferInstruction-args] 
'\002\000\000\000S\217\255%PD...' 65504 bytes
[server: copy] 
getFile(/disk2/brooks/temp/a,ARFM2004_Weinstein_Coating_Flows_preprint.pdf) -> 
(/disk
2/brooks/temp/a,.#ARFM2004_Weinstein_Coating_Flows_preprint.pdf.54546f.unison.tmp,ARFM2004_Weinstein
_Coating_Flows_preprint.pdf,modified on 2005-09-15 at 11:26:07  size 229518
read-write)
[server: copy] src file size = 229518 bytes
[server: copy] startReceivingFile: 
/disk2/brooks/temp/a/.#ARFM2004_Weinstein_Coating_Flows_preprint.
[remote_emit] send [rsp] '\132\149\166\190\000\000\000\028\000\000...' 48 bytes
[remote_emit] Sending request (id: 12)

[server: remote_emit] send [compress-args] 
'\132\149\166\190\000\000\000Z\000\000...' 110 bytes
[server: remote_emit] send [rsp] '\132\149\166\190\000\000\000\n\000\000...' 30 
bytes
[server: remote_emit] Sending request (id: 3)
[server: remote_emit] Remaining tokens: 1
[server: remote_emit] Remaining tokens: 0
[server: remote_emit] Sending write token
[server: remote_emit] Restarting reader
[server: remote_emit] Waiting for next message
[remote_emit] Remaining tokens: 0
[remote_emit] Sending write token
[remote_emit] Restarting reader
[remote_emit] Waiting for next message
[server: remote_emit] Message received (id: 12) (tokens: 1)
[server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...' 51 bytes


(At that point, it simply hangs and does nothing.)


--
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: Why does stat fail for some files?

[Brian Dessent]

Mikael wrote:

> Hello, I'm doing homework and I'm having some problems with stat() failing.
> Consider the following C program:

Your program contains a logic flaw that causes it to work only if the
path specified is the CWD.  Since it's homework (!!) you'll have to
figure it out for yourself.

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: Bug in gcc and/or binutils?

[Gerrit P. Haase]

Peter Ekberg wrote:


Hi!

I have been looking at a failure in the testsuite in
libtool-cvs which I have reduced to the following
script. I have included the approximate output from
any program execed by it in comments along with
comments as to what is going wrong.

$ gcc --version | head -1
gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
$ ld --version | head -1
GNU ld version 2.16.91 20050610

Etc etc yada yada updated the Cygwin installation the
other day...

This limitation is perhaps already known?


Not that I'm aware of.  I try to avoid using .def files anyway.  But I
can confirm that I get the same results.  I suspect some change in
binutils, at least also dlltool fails to create a proper import library
when this .def file is used, just change the script like this to see:

 run gcc -shared -o a.dll a.o
 run dlltool --as=as --dllname a.dll --def a.def --output-lib a.bad.lib

instead of:

 run gcc -shared a.def a.o -o a.dll -Wl,--out-implib,a.bad.lib


However DATA handling was changed in gcc too.

To avoid these kind of problems you must define whether you're exporting 
DATA or not, then it will work:


a.def---
EXPORTS
v7 @1 DATA
a.def---

The old impgen tool included with libtool fails to proper declare
whether some symbol is DATA or not.  So IMO it is a bug in libtool.

At first I thought it might be a problem with the D compiler frontend
included with gcc because .d may trigger some special logic in gcc,
however, trying the same with dlltool shows that this may not the reason
for this issue.

Thank you very much for this detailed analysis, I'll try to investigate
further, because some of the Gnome base packages use .def files too,
maybe this is the reason why I cannot get the Gnome desktop up and
running with the latest releases.  However, I see no apps crashing
(besides Mozilla).


Gerrit
--
=^..^=

--
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: [ANNOUNCEMENT] Updated: more-2.11o-2

[Brooks Moses]

Eric Blake wrote:

A new release of more, 2.11o-2, is available.

NEWS:
=
This is a minor bugfix release - more was recompiled against newer
versions of libraries so that it can now access large files and no longer
has the security flaw of the older regular expression parser libpcre.


I just installed this, and noticed that selecting it for install also 
selects vim -- a rather startling 3MB download for a "minor bugfix"!  Is 
that because the newer versions of the libraries are in the vim package, 
or is it in error?


Thanks,
- Brooks


--
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: [ANNOUNCEMENT] Updated: more-2.11o-2

[Eric Blake]

> Eric Blake wrote:
> > A new release of more, 2.11o-2, is available.
> > 
> > NEWS:
> > =
> > This is a minor bugfix release - more was recompiled against newer
> > versions of libraries so that it can now access large files and no longer
> > has the security flaw of the older regular expression parser libpcre.
> 
> I just installed this, and noticed that selecting it for install also 
> selects vim -- a rather startling 3MB download for a "minor bugfix"!  Is 
> that because the newer versions of the libraries are in the vim package, 
> or is it in error?

more has a feature where it can invoke your editor.  If VISUAL and
EDITOR are undefined in your environment, it insists that 'vi'
exist somewhere on your path.  I ensured this was the case by
editing setup.hint accordingly.  However, this may have been
a bit extreme, so cgf may want to remove vim as a dependency
in the setup.hint, now that he has volunteered to be the more
maintainer.

--
Eric Blake



--
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: Why does stat fail for some files?

[Mikael]

Eric Blake wrote:
>> Hello, I'm doing homework and I'm having some problems with stat()
>> failing.
>
> It's called homework for a reason, but here are some hints:

Come on, at least I just didn't post the assignment without a single line 
code and waited
for someone to fix it for me like I see alot on different forums and 
newsgroups. I've put effort into this and I also tried to use a readable 
coding style.

>
>> Consider the following C program:
>>
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> #include 
>> #include 
>> #include 
>>
>> static void scan_directory(const char *);
>>
>> int
>> main(int argc, char **argv)
>> {
>>if(argc == 1)
>>{
>>   fprintf(stderr, "Usage: dirscan path\n");
>>
>>   return EXIT_FAILURE;
>>}
>>
>>scan_directory(argv[1]);
>>
>>return EXIT_SUCCESS;
>> }
>>
>> static void
>> scan_directory(const char *path)
>> {
>>DIR *directory = NULL;
>>struct dirent *entry = NULL;
>>struct stat statbuf;
>>int return_value = 0;
>>
>>directory = opendir(path);
>>
>>if(!directory)
>>{
>>   fprintf(stderr, "Directory %s could not be opened.\n", path);
>
> fprintf can clobber errno...
>
>>   fprintf(stderr, "Reason: %s\n", strerror(errno));
>
> so you may be printing the wrong reason.
>
>>
>>   /* Don't exit program, we may have been called recursively and
>>  we want to scan what we can.
>>   */ return;
>>}
>>
>>while((entry = readdir(directory)))
>
> You just ignored the possibility that readdir might set errno.
>
>>{

Ok, I can set errno to 0 before I call stat(), but I was under the 
impression that if stat() fails it will overwrite the current value of errno 
with a new one indicating the error. And since I determine if an error 
occured by checking the return value of stat() and *then* checking errno if 
the return value was != 0 instead of looking at errno directly, isn't my way 
safe even if errno was nonzero before the call?

>>   return_value = stat(entry->d_name, &statbuf);
>
> Hmm - think relative vs. absolute pathname, then consider where
> you invoked your command.

Ah, that's it! readdir() is looking at the directory I supplied as a command 
line argument, but stat() is looking at the cwd. And in the cwd I happen to 
have a files called "Makefile", ".", and, "..", respectively. but not the 
other files found by readdir(). So I to change the call to stat() so it gets 
the whole path to the files found by readdir(). Thanks very much!

>
>>
>>   if(return_value)
>>  fprintf(stderr, "stat() failed for %s. Reason: %s\n",
>>entry->d_name, strerror(errno));
>>   else
>>  printf("stat() called successfully on: %s\n",
>>entry->d_name); }
>>
>>return_value = closedir(directory);
>>
>>assert(!return_value); /* closedir() returns 0 on success */
>> }
>>
>> And this is what happens when I run it (first ls -al):
>> $ ls -al /c/cygwin/home/mikael/coding/cygwin/c++/read_directory/
>> total 773
>> drwxrwxrwx+  2 mikael None  0 Sep 15 16:36 ./
>> drwxrwxrwx+ 16 mikael None  0 May 20 22:53 ../
>> -rwxrwxrwx   1 mikael None273 Sep 15 16:36 Makefile*
>> -rwxrwxrwx   1 mikael None792 Aug 19  2004 read_directory.cpp*
>> -rwxr-xr-x   1 mikael None 604746 Sep 15 16:36 read_directory.exe*
>> -rw-r--r--   1 mikael None 129520 Sep 15 16:36 read_directory.o
>>
>> $ ./dirscan.exe
>> /c/cygwin/home/mikael/coding/cygwin/c++/read_directory/ stat()
>> called successfully on: .
>> stat() called successfully on: ..
>> stat() called successfully on: Makefile
>> stat() failed for read_directory.cpp. Reason: No such file or
>> directory stat() failed for read_directory.exe. Reason: No such file
>> or directory stat() failed for read_directory.o. Reason: No such
>> file or directory
>
> As a side note, Windows has the annoying habit that when a file
> is locked by another application, stat() won't get much information
> about the file, but at least it won't fail.

Interesting...I will be sure keep that in mind if I encounter other problems 
with stat() being non-informative.

Thanks for the quick reply, Eric!

/ Mikael 




--
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: [ANNOUNCEMENT] Updated: more-2.11o-2

[Christopher Faylor]

On Thu, Sep 15, 2005 at 08:23:45PM +, Eric Blake wrote:
>> Eric Blake wrote:
>> > A new release of more, 2.11o-2, is available.
>> > 
>> > NEWS:
>> > =
>> > This is a minor bugfix release - more was recompiled against newer
>> > versions of libraries so that it can now access large files and no longer
>> > has the security flaw of the older regular expression parser libpcre.
>> 
>> I just installed this, and noticed that selecting it for install also 
>> selects vim -- a rather startling 3MB download for a "minor bugfix"!  Is 
>> that because the newer versions of the libraries are in the vim package, 
>> or is it in error?
>
>more has a feature where it can invoke your editor.  If VISUAL and
>EDITOR are undefined in your environment, it insists that 'vi'
>exist somewhere on your path.  I ensured this was the case by
>editing setup.hint accordingly.  However, this may have been
>a bit extreme, so cgf may want to remove vim as a dependency
>in the setup.hint, now that he has volunteered to be the more
>maintainer.

Hmm.  I guess I'll remove it but I see why you added it.

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: Why does stat fail for some files?

[Eric Blake]

I'm glad to see you figured out your bug.  Now for another hint:
judicious use of chdir() can save you the effort of concatenating
the directory name with the entry name.

> >>while((entry = readdir(directory)))
> >
> > You just ignored the possibility that readdir might set errno.
> >
> >>{
> 
> Ok, I can set errno to 0 before I call stat(), but I was under the 
> impression that if stat() fails it will overwrite the current value of errno 
> with a new one indicating the error. And since I determine if an error 
> occured by checking the return value of stat() and *then* checking errno if 
> the return value was != 0 instead of looking at errno directly, isn't my way 
> safe even if errno was nonzero before the call?

No.  The point here is that ignoring the errno on ANY syscall is
bad practice, and a habit to be broken before it begins, even
though it may be unlikely that the call ever fails.  With
readdir(), the standard safe usage pattern is to assign errno to
0 just before readdir, then if readdir returns NULL, check if errno
is still 0 (you are done, succesfully) or not (readdir failed).

> >>entry->d_name); }
> >>
> >>return_value = closedir(directory);

It is right here, when your while loop ends, that you didn't
check to see if readdir failed, and therefore, you don't know
if you finished reading the directory before you tried closing it.

> 
> Thanks for the quick reply, Eric!

Also, questions like this should probably be directed to other
lists, since it was not cygwin specific.

--
Eric Blake



--
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: Why does stat fail for some files?

[Christopher Faylor]

On Thu, Sep 15, 2005 at 08:38:35PM +, Eric Blake wrote:
>> Thanks for the quick reply, Eric!
>
>Also, questions like this should probably be directed to other
>lists, since it was not cygwin specific.

Absolutely.  Even putting the issue of helping someone with their
homework aside, this certainly isn't a mailing list for helping
people learn how to program.

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/

1:5:16 XP Is there a strings program?

[Trevor Osatchuk]

I was looking for the strings functionality in cygwin.  I googled it
and saw that strings.exe should be in bin/utils, but I don't have it. 
I ran my installation again to see if it was an option that I could,
but it wasn't there.

Thanks,

fybar

--
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: testers needed prior to 1.5.19 release

[Angelo Graziosi]

Using the snap 20050914 20:03:52


As I wrote the snap 20050914 20:03:52 fixed the problems with Borland C++
applications ("spawn.cc (av::fixup): Guard against problems reading an
executable which does not match Microsoft's documentation about PE
format") etc.

But I observed the following behaviour.

Running 'X' with startxwin.bat, when one tries to close the xterm window
clicking on 'x' button, the window is closed only after about 60 s!

There are no problems if one uses 'logout' or 'exit' or if one closes
directly the X server right clicking on the X-icon in sys stray.

The same behaviour is showed by snap 20050914 20:32:51
    --


Snap 20050915 12:06:56
==

With this snap the things get worse.

That behaviour remains but the keyboard layout is changed: the key '-'
prints '/', etc..

Not only.  
For the applications which failed with 'Argument...too long' now, Windows
(W2K SP4) says: ".. the application is not correctly initialized press OK
to close..."




In any case using Cygwin.bat (not using X) seems to work without that
behaviour of delay the closing of the xterm window.


Best regards,

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/

Re: 1:5:16 XP Is there a strings program?

[Eric Blake]

> I was looking for the strings functionality in cygwin.  I googled it
> and saw that strings.exe should be in bin/utils, but I don't have it. 
> I ran my installation again to see if it was an option that I could,
> but it wasn't there.

It is part of the "binutils" package, which can be selected with
setup.exe, and not a program in the mythical "bin/utils"
subdirectory.  It gets installed as /bin/strings.exe and
/usr/bin/strings.exe.

Follow these directions to help us help you.
> Problem reports:   http://cygwin.com/problems.html

Based on your message subject, you are running an older version
of cygwin, and it is worth upgrading cygwin to 1.5.18 when you
grab the binutils package.  It is all done with the same setup.exe
program.

--
Eric Blake



--
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:16 XP Is there a strings program?

[René Berber]

Trevor Osatchuk wrote:

> I was looking for the strings functionality in cygwin.  I googled it
> and saw that strings.exe should be in bin/utils, but I don't have it. 
> I ran my installation again to see if it was an option that I could,
> but it wasn't there.

  http://cygwin.com/cgi-bin2/package-grep.cgi?grep=strings.exe

-- 
René Berber


--
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:16 XP Is there a strings program?

[Trevor Osatchuk]

Thanks to both of you.  I am updating and have selected binutils to added.

On 9/15/05, René Berber <[EMAIL PROTECTED]> wrote:
> Trevor Osatchuk wrote:
> 
> > I was looking for the strings functionality in cygwin.  I googled it
> > and saw that strings.exe should be in bin/utils, but I don't have it.
> > I ran my installation again to see if it was an option that I could,
> > but it wasn't there.
> 
>  http://cygwin.com/cgi-bin2/package-grep.cgi?grep=strings.exe
> 
> --
> René Berber
> 
> 
> --
> 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/

A couple Issues with cygwin1-20050915.dll

[James R. Phillips]

Testing the latest 20050915 snapshot, saw a couple issues:

1) Max length of command line inside a makefile seems to have shortened, to
around 250 characters max.  This is based on a clean command that has a make
macro that expands to a relatively long list of files.  When the resulting
command line exceeds something around 250 characters, make returns error 3. 
Does not happen with 1.5.18.

2) cygcheck itself prints an error message like this:

$ cygcheck
  6 [main] ? 2756 fork_copy: cygheap pass 0 failed, 0x6115A920..0x6115E624,
done 0, windows pid 3892, Win32 error 5
Usage: cygcheck [OPTIONS] [PROGRAM...]

[This happens whether or not a proper argument list is passed].

cygcheck output attached.

jrp

cygcheck.out
Description: 3924260979-cygcheck.out
--
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/

cygwin forgets CTRL key press

[Luke Kendall]

Has anyone else noted that in vi (either in a plain Cygwin window or in
an rxvt window, in an X session or not, also in xterm), that if you hold
down the CTRL key and press keys at intervals (like F to page down
through a file), and wait four seconds before another key press it's as
if you don't have CTRL pressed at all?  You have to release it and press
afresh.

The same applies to "more": hold CTRL down and press f, and it beeps at
you to indicate that's invalid; still hold CTRL down, wait 4 seconds,
then press f again, and it pages forward.

This behaviour has been present for years, BTW, it's not new.

luke


--
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: A new day, a new snapshot, more testing required on the road to 1.5.19

[Volker Quetschke]

However, I *really* do appreciate all of the testing that we've seen so
far.  I hope everyone who has tested previous snapshots will continue to
test this one and any other snapshots up until I eventually release 1.5.19.


I saw that 20050915 was out and started the OOo testsuite again ;)

The attached script is the codensed part of configure that tests if ant
is installed and usable.

If you set $ANT and $JAVA_HOME in the script correctly this is supposed
to succeed. It does for 20050914 and older versions, it does *sometimes*
for 20050915.

Volker

P.S.: The 9MB testcase seems to be fixed with the new snapshot.

P.P.S: Yes, JAVA_HOME must be posix format, and uses cygpath
   and converts it into DOS style.

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

export JAVA_HOME="/cygdrive/c/j2sdk1.4.2_05"
export ANT="/cygdrive/c/apache-ant-1.6.5/bin/ant"

cat > conftest.java << EOF
public class conftest {
int testmethod(int a, int b) {
return a + b;
}
}
EOF

cat > conftest.xml << EOF






EOF

while true; do

date

rm -f conftest.class

ant_cmd="$ANT -buildfile conftest.xml 1>&2 >qq"
eval $ant_cmd

mystatus=$?

if test $mystatus != 0 ; then
  echo test failed
#  exit 1
else
  echo test OK
fi

done

signature.asc
Description: OpenPGP digital signature

Re: A new day, a new snapshot, more testing required on the road to 1.5.19

[Volker Quetschke]

P.P.S: Yes, JAVA_HOME must be posix format, and uses cygpath

--^^^ ANT

   and converts it into DOS style.


--
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: A new day, a new snapshot, more testing required on the road to 1.5.19

[Christopher Faylor]

On Thu, Sep 15, 2005 at 08:29:38PM -0400, Volker Quetschke wrote:
>>However, I *really* do appreciate all of the testing that we've seen so
>>far.  I hope everyone who has tested previous snapshots will continue to
>>test this one and any other snapshots up until I eventually release 1.5.19.
>
>I saw that 20050915 was out and started the OOo testsuite again ;)
>
>The attached script is the codensed part of configure that tests if ant
>is installed and usable.
>
>If you set $ANT and $JAVA_HOME in the script correctly this is supposed
>to succeed. It does for 20050914 and older versions, it does *sometimes*
>for 20050915.

Yes, I'm not quite ready to send out a new try a snapshot.  There are some
things I need to check.

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: cygwin forgets CTRL key press

[Larry Hall]

At 07:25 PM 9/15/2005, you wrote:
>Has anyone else noted that in vi (either in a plain Cygwin window or in
>an rxvt window, in an X session or not, also in xterm), that if you hold
>down the CTRL key and press keys at intervals (like F to page down
>through a file), and wait four seconds before another key press it's as
>if you don't have CTRL pressed at all?  You have to release it and press
>afresh.
>
>The same applies to "more": hold CTRL down and press f, and it beeps at
>you to indicate that's invalid; still hold CTRL down, wait 4 seconds,
>then press f again, and it pages forward.
>
>This behaviour has been present for years, BTW, it's not new.


I've never seen this and cannot reproduce it locally based on the 
procedure you described.



--
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: Bug in gcc and/or binutils?

[Charles Wilson]

FWIW, this is not a "recent" regression --- nothing "changed" in 
binutils or gcc.  I just installed binutils-20040725-2 from the Cygwin 
Time Machine and got identical output.  This was a surprise to me:


*I* thought that we no longer needed the DATA flag in .def files because 
binutils was smart enough to figure that out on its own -- obviously, it 
does so when auto-EXporting, so why can't it do so when using a .def 
file?  Using .def files turns off the auto-EXport logic (which it 
should, because if you specify a specific set of exports you don't want 
binutils adding a few more on its own).


However, this "turn off the auto-EXport logic" seems to include turning 
off the "is this symbol a DATA item or a function" logic.  I never knew 
that.



So, given my mistaken understanding, I wanted to know if this was a 
recent "regression" in binutils.  But, it's always been like that -- it 
is not a regression at all.


The question is, should binutils be "fixed" to keep the "is this symbol 
a DATA item or a function" logic active even when using .def files?  I'm 
not sure the answer is yes.  Wouldn't this imply giving binutils 
override power, if I marked a *function* symbol with 'DATA' in the .def 
file -- the converse of the case described by Gerritt?  Basically, we'd 
be making binutils IGNORE any 'DATA' (or lack thereof) decoration in the 
.def file, and just "do what it thinks is best".


This doesn't seem to be the path of wisdom, to me.  If I'm using a .def 
file, it's likely because in the specific situation I don't trust 
binutils to "do what it thinks is best"; if I did, I'd let the 
auto-EXport logic do its thing.   So, to me it looks more and more that 
libtool ought to be more careful when creating its .def file...



Which is the long-winded way of saying that I agree with Gerritt.

--
Chuck

--
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 forgets CTRL key press

[Igor Pechtchanski]

On Fri, 16 Sep 2005, Luke Kendall wrote:

> Has anyone else noted that in vi (either in a plain Cygwin window or in
> an rxvt window, in an X session or not, also in xterm), that if you hold
> down the CTRL key and press keys at intervals (like F to page down
> through a file), and wait four seconds before another key press it's as
> if you don't have CTRL pressed at all?  You have to release it and press
> afresh.
>
> The same applies to "more": hold CTRL down and press f, and it beeps at
> you to indicate that's invalid; still hold CTRL down, wait 4 seconds,
> then press f again, and it pages forward.
>
> This behaviour has been present for years, BTW, it's not new.

I suspect it's not Cygwin-related.  This sounds like the Windows "sticky
keys" accessibility feature -- if any modifier key is held for some period
of time (more than 8 seconds, I think), Windows offers to turn on sticky
keys.  Even if the feature is disabled, the 8-second timer may be started
every time the key is pressed.  I wouldn't be surprised if this is the
cause of the behavior you observe...
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!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

--
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 forgets CTRL key press

[Luke Kendall]

On 15 Sep, Igor Pechtchanski wrote:
>  On Fri, 16 Sep 2005, Luke Kendall wrote:
>  
> > Has anyone else noted that in vi (either in a plain Cygwin window or in
> > an rxvt window, in an X session or not, also in xterm), that if you hold
> > down the CTRL key and press keys at intervals (like F to page down
> > through a file), and wait four seconds before another key press it's as
> > if you don't have CTRL pressed at all?  You have to release it and press
> > afresh.
>  >
> > The same applies to "more": hold CTRL down and press f, and it beeps at
> > you to indicate that's invalid; still hold CTRL down, wait 4 seconds,
> > then press f again, and it pages forward.
>  >
> > This behaviour has been present for years, BTW, it's not new.
>  
>  I suspect it's not Cygwin-related.  This sounds like the Windows "sticky
>  keys" accessibility feature -- if any modifier key is held for some period
>  of time (more than 8 seconds, I think), Windows offers to turn on sticky
>  keys.  Even if the feature is disabled, the 8-second timer may be started
>  every time the key is pressed.  I wouldn't be surprised if this is the
>  cause of the behavior you observe...
>   Igor

I checked, but found that I have "Sticky keys" turned off in the control
panel accessibility options.

Also, I've timed it roughly and it's close to 4 seconds, not 8.  And if
it's due to this, wouldn't Larry have been able to reproduce it??

I'm now checking with other Cygwin users here to see if we can see what
controls the reproducibility.  I'll let you know the results.

(BTW, FWIW I'm running Windows XP sp1.)

Regards,

luke


--
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 forgets CTRL key press

[Larry Finger]

Luke Kendall wrote:

On 15 Sep, Igor Pechtchanski wrote:


On Fri, 16 Sep 2005, Luke Kendall wrote:



Has anyone else noted that in vi (either in a plain Cygwin window or in
an rxvt window, in an X session or not, also in xterm), that if you hold
down the CTRL key and press keys at intervals (like F to page down
through a file), and wait four seconds before another key press it's as
if you don't have CTRL pressed at all?  You have to release it and press
afresh.


>


The same applies to "more": hold CTRL down and press f, and it beeps at
you to indicate that's invalid; still hold CTRL down, wait 4 seconds,
then press f again, and it pages forward.


>


This behaviour has been present for years, BTW, it's not new.



I suspect it's not Cygwin-related.  This sounds like the Windows "sticky
keys" accessibility feature -- if any modifier key is held for some period
of time (more than 8 seconds, I think), Windows offers to turn on sticky
keys.  Even if the feature is disabled, the 8-second timer may be started
every time the key is pressed.  I wouldn't be surprised if this is the
cause of the behavior you observe...
Igor



I checked, but found that I have "Sticky keys" turned off in the control
panel accessibility options.

Also, I've timed it roughly and it's close to 4 seconds, not 8.  And if
it's due to this, wouldn't Larry have been able to reproduce it??

I'm now checking with other Cygwin users here to see if we can see what
controls the reproducibility.  I'll let you know the results.

(BTW, FWIW I'm running Windows XP sp1.)

Regards,

luke




Could it be in the firmware on the keyboard? Is it possible to try another?

Larry


--
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: Bug in gcc and/or binutils?

[Danny Smith]

References: 


Charles Wilson   wrote:

>
> Using .def files turns off the auto-EXport logic (which it should,
> because if you specify a specific set of exports you don't want binutils
> adding a few more on its own).

There seems to be a common misconception that auto-export logic and
explicit designation of exports are incompatible.
You can still use --export-all  (to get the auto-export of all defined
symbols) with a .def file or with __declspec(dllexport).

eg
gcc -shared -ofoo.dll foo.def foo.c -Wl,--export-all

The use of a def file (with --export-all) is useful when you want to
export all symbols but want special handling of some, say an alias or
marking a symbol as PRIVATE (exclude from import lib) or NONAME (exclude
the name of the symbol from the dll's export table), (almost like
__attribute__((hidden)) Or you may want to add a symbol that is just
forwarded to another dll. Or you have a function foo() but only want
the indirect ref __imp__foo visible in the import lib, and not the label:

foo:
  jmp * __imp__foo

so you only export the pointer  by marking as DATA in the def file

Danny


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

Python extension package problem & root-cause

[John Whitley]

The following is derived from a bug report that I've filed on Python  
that affects
building and installing extension packages on the Cygwin platform.   
I'm posting this here to assist any other Cygwin users affected by  
this problem.  URL for the Python bug

report is:

http://sourceforge.net/tracker/index.php? 
func=detail&aid=1289136&group_id=5470&atid=105470


-- John Whitley

--

A while back I reported a problem on the Cygwin mailing list where all
python extension packages would fail "python setup.py install" at the
link step due to a mangled lib dir (-L) option. distutils was
producing a link line with "-L.", instead of the desired
"-L/usr/lib/python2.4/config". I've finally rooted out the cause of
this problem.

The relevant code is the if-block starting at line 188 of:
/usr/lib/python2.4/distutils/command/build_ext.py

I've reproduced that block here for clarity of
discussion (indentation truncated for redability)

if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos':
if string.find(sys.executable, sys.exec_prefix) != -1:
   # building third party extensions
   self.library_dirs.append(os.path.join(sys.prefix, "lib",
 "python" +  
get_python_version(),

 "config"))
else:
   # building python standard extensions
   self.library_dirs.append('.')

The test "string.find(...) != -1" attempts to test whether "/usr"
appears in the full executable name.  This incorrectly fails in the
case that /bin is in the user's path before /usr/bin
(i.e. string.find("/bin/python","/usr") == -1).  Note that a vagary of
Cygwin is that /usr/bin is a Cygwin mount to /bin.

Workaround:

The workaround is to ensure that /usr/bin appears in your path before
/bin. It looks like a new and improved Cygwin special case test is
needed to fix this problem; I'm not sure offhand what the best case
would be. Perhaps an outright test as follows would work:
sys.executable.startswith(sys.exec_prefix) or
sys.executable.startswith(os.sep+"bin")


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