Re: [ITP] re2c (3rd try)
Gerrit P. Haase wrote: Hello Max, you wrote: The package does build now, but I think it would be best to follow Igor's comments about lnconf.sh. The package should not unpack files to /usr/src that do not contain the package's name and version, to guarantee that they will not conflict with other packages. Ok, I moved it to the CYGWIN-PATCHES directory. The build does work, but I why modify lnconf.sh ? IMO, the point of having a standard is so that knowledge of building Cygwin packages is transferrable from package to package. So, it would be nicer if you used lnconf.sh in the way it was intended, without modification. It would be useful to put note in the README, explaining why many files in the bootstrap directory have been patched. Also, I see that uchar has been changed to char in scanner.re and files created from it - it would be good to change the examples too, if this change is a required one. I added a note to the README. I used another patch now which is much smaller which I found in the debian re2c package. The samples: The generated code doesn't compile on Cygwin. There are more changes needed to get valid code out of the the examples. The code base in CVS is updated to use istream (ifstream or cin) instead of unix open/read/close which will be in cluded in future releases. OK, fair enough. Max.
[ITP] re2c (3rd try)
Hello Max, you wrote: The package does build now, but I think it would be best to follow Igor's comments about lnconf.sh. The package should not unpack files to /usr/src that do not contain the package's name and version, to guarantee that they will not conflict with other packages. Ok, I moved it to the CYGWIN-PATCHES directory. It would be useful to put note in the README, explaining why many files in the bootstrap directory have been patched. Also, I see that uchar has been changed to char in scanner.re and files created from it - it would be good to change the examples too, if this change is a required one. I added a note to the README. I used another patch now which is much smaller which I found in the debian re2c package. The samples: The generated code doesn't compile on Cygwin. There are more changes needed to get valid code out of the the examples. The code base in CVS is updated to use istream (ifstream or cin) instead of unix open/read/close which will be in cluded in future releases. Complete updated package: http://anfaenger.de/cygwin/re2c/setup.hint http://anfaenger.de/cygwin/re2c/re2c-0.9.1-1.tar.bz2 http://anfaenger.de/cygwin/re2c/re2c-0.9.1-1-src.tar.bz2 Gerrit -- =^..^=
Re: [ITP] re2c (3rd try)
Hi Max, The build does work, but I why modify lnconf.sh ? IMO, the point of It doesn't work for me as it is. I think it should be inlined in the generic-build-script so you may choose to call conf or lnconf at any time simply by changing the list for the 'all' target. having a standard is so that knowledge of building Cygwin packages is transferrable from package to package. So, it would be nicer if you used lnconf.sh in the way it was intended, without modification. There is no documentation, I couldn't figure out how it should be used (I tried really hard in these five minutes). Gerrit -- =^..^=
Re: [ITP] re2c (3rd try)
Gerrit P. Haase wrote:
Hi Max,
The build does work, but I why modify lnconf.sh ? IMO, the point of
It doesn't work for me as it is. I think it should be inlined in the
generic-build-script so you may choose to call conf or lnconf at any time
simply by changing the list for the 'all' target.
having a standard is so that knowledge of building Cygwin
packages is transferrable from package to package. So, it would be
nicer if you used lnconf.sh in the way it was intended, without
modification.
There is no documentation, I couldn't figure out how it should be used
(I tried really hard in these five minutes).
The original intent (AFAICS) was for you to be able to simply use the contents of
lnconf.sh as ${srcdir}/configure, and then use an
unmodified g-b-s. Unfortunately, that plan is spoilt, because patch doesn't restore
the execute mode on new files. You can avoid
that by calling it via sh:
conf() {
(cd ${objdir} \
sh ${srcdir}/lnconf.sh )
}
Although, it would be more convenient if g-b-s did:
if [ -f ${srcdir}/lnconf.sh ]; then
# do the above
else
# do the existing configure code
fi
Igor, what do you think?
Max.
Re: [ITP] re2c (3rd try)
Hi Max schri
The original intent (AFAICS) was for you to be able to simply use
the contents of lnconf.sh as ${srcdir}/configure, and then use an
unmodified g-b-s. Unfortunately, that plan is spoilt, because patch
doesn't restore the execute mode on new files. You can avoid
that by calling it via sh:
Ah well, it needs to be in the source directory where configure is.
Well, I thought it would act like `lndir frompath` which symlinks the
frompath to pwd. And I think it should do this, regardless where the
script is located!
conf() {
(cd ${objdir} \
sh ${srcdir}/lnconf.sh )
}
Although, it would be more convenient if g-b-s did:
if [ -f ${srcdir}/lnconf.sh ]; then
# do the above
else
# do the existing configure code
fi
Looks ok.
Gerrit
--
=^..^=
[PATCH] for generic-build-script
Hallo cygwin-apps,
--- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
+++ generic-build-script2004-05-19 15:49:41.196923200 +0200
@@ -180,7 +180,7 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
fi \
if [ -d ${instdir}${prefix}/share/man ] ; then \
find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
# END OF ANNOUNCEMENT
Gerrit
--
=^..^=
Re: [PATCH] for generic-build-script
On Wed, May 19, 2004 at 03:52:04PM +0200, Gerrit P. Haase wrote:
Hallo cygwin-apps,
--- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
+++ generic-build-script2004-05-19 15:49:41.196923200 +0200
@@ -180,7 +180,7 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
-name * is a no-op. You can just remove it.
Also, shouldn't all of these directories be quoted, i.e:
find ${instdir}${prefix}/share/info -print0 | xargs -0 gzip -q
cgf
Re: [PATCH] for generic-build-script
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerrit P. Haase wrote:
| Hallo cygwin-apps,
|
| --- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
| +++ generic-build-script2004-05-19 15:49:41.196923200 +0200
| @@ -180,7 +180,7 @@
| fi ;\
|done \
|if [ -d ${instdir}${prefix}/share/info ] ; then \
| -find ${instdir}${prefix}/share/info -name *.info | xargs gzip
- -q ; \
| +find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
|fi \
|if [ -d ${instdir}${prefix}/share/man ] ; then \
| find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
|
| # END OF ANNOUNCEMENT
Gerrit,
Could you explain your reasoning behind this patch? Since I contributed
this part of the g-b-s, let me explain this. Basically, I wanted to
make sure that we were gzipping just the man and info pages, not
subdirs, and not pages that were already compressed (I've built a couple
of programs that would gzip the man pages themselves on install).
But I see now with the info pages that it's more complicated than *.info
in the cases when there are multiple info page files for one program,
such as gcc, gdb, make, emacs, etc. Is that what your intention is?
If so, let me propose the attached patch instead. These changes should
make sure that:
1) all pages are being compressed, no matter how they are named;
2) only files are being compressed;
3) pages already compressed won't be compressed again;
4) if no qualifying pages are found, gzip won't complain (xargs -r).
Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAq5qJpiWmPGlmQSMRAlQVAJ4vTbWKY0glYWmolz9QQhyoFEGYRACgrsPv
mJ9kH/pEDur2oHxLup+vFzI=
=vmxV
-END PGP SIGNATURE-
--- generic-build-script-orig 2004-05-19 13:08:39.923334400 -0400
+++ generic-build-script2004-05-19 13:18:17.343624000 -0400
@@ -180,12 +180,12 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -type f ! -name *.gz \
+ | xargs -r gzip -q ; \
fi \
if [ -d ${instdir}${prefix}/share/man ] ; then \
-find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
- -name *.3x -o -name *.3pm -o -name *.5 -o -name *.6 -o \
- -name *.7 -o -name *.8 | xargs gzip -q ; \
+find ${instdir}${prefix}/share/man -type f ! -name *.gz \
+ | xargs -r gzip -q ; \
fi \
templist= \
for f in ${install_docs} ; do \
Re: [PATCH] for generic-build-script
On Wed, 19 May 2004, Christopher Faylor wrote:
On Wed, May 19, 2004 at 03:52:04PM +0200, Gerrit P. Haase wrote:
Hallo cygwin-apps,
--- generic-build-script~ 2004-05-19 15:49:55.827961600 +0200
+++ generic-build-script2004-05-19 15:49:41.196923200 +0200
@@ -180,7 +180,7 @@
fi ;\
done \
if [ -d ${instdir}${prefix}/share/info ] ; then \
-find ${instdir}${prefix}/share/info -name *.info | xargs gzip -q ; \
+find ${instdir}${prefix}/share/info -name * | xargs gzip -q ; \
-name * is a no-op. You can just remove it.
Yep. I think what was intended here was -type f.
Also, shouldn't all of these directories be quoted, i.e:
find ${instdir}${prefix}/share/info -print0 | xargs -0 gzip -q
cgf
True, but, AFAICS, the whole GBS suffers from this. I should make a pass
and fix all of them in one sweep.
Gerrit, how about a resubmit, with or without the quoting, but with a
ChangeLog?
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!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Re: [ITP] re2c (3rd try)
On Wed, 19 May 2004, Max Bowsher wrote:
Gerrit P. Haase wrote:
Hi Max,
The build does work, but I why modify lnconf.sh ? IMO, the point of
It doesn't work for me as it is. I think it should be inlined in the
generic-build-script so you may choose to call conf or lnconf at any time
simply by changing the list for the 'all' target.
having a standard is so that knowledge of building Cygwin
packages is transferrable from package to package. So, it would be
nicer if you used lnconf.sh in the way it was intended, without
modification.
There is no documentation, I couldn't figure out how it should be used
(I tried really hard in these five minutes).
The original intent (AFAICS) was for you to be able to simply use the
contents of lnconf.sh as ${srcdir}/configure, and then use an unmodified
g-b-s.
Exactly.
Unfortunately, that plan is spoilt, because patch doesn't restore the
execute mode on new files.
Whoops! Didn't think of that...
You can avoid that by calling it via sh:
conf() {
(cd ${objdir} \
sh ${srcdir}/lnconf.sh )
}
Although, it would be more convenient if g-b-s did:
if [ -f ${srcdir}/lnconf.sh ]; then
# do the above
else
# do the existing configure code
fi
Igor, what do you think?
Max.
I like the former approach better, frankly (except that I'm not very
comfortable with hardcoding lnconf.sh into the GBS, so we should just
always execute configure via sh). Or, maybe we should just say
[ -x ${srcdir}/configure ] || chmod +x ${srcdir}/configure
instead, and then let events take their normal course... This will also
cover cases when the configure script included with the original source
tarball lacks execute permissions (rare, but possible, I guess).
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!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
Cannot start X because of error with cygwin1.dll
Hi All I'm new to this, so I may be doing something stupid, anyhow I've made sure that the dll is in the same folder as the startX batch files etc which on my system is C:\cygwin\usr\X11R6\bin Now when I try to start X I get the error message The procedure entry point _fcntl64 could not be located in the dynamic link library cygwin1.dll Can anyone tell me, what I need to do to get X working please Cheers Stephen Whipp
XWin and the ICON on xterm window
Hi, From version 6.7-5 I have noted that starting XWin with startxwin.bat (.sh) produces an xterm window for which the X-Icon near its title looks corrupted, as if there were a double reflection/refraction. Also others X-Windows application (like emacs) presents this effect. The X-Icon of the X-Server on bottom-right of application bar it is OK!. What's happened? Using XWin.exe of v. 6.7-4 the icons are all OK. Angelo. [EMAIL PROTECTED]
RE: Using 6.7.0.0-8 Failure to connect to Linux
On Wed, 12 May 2004, Crystal Martin wrote: Hello! I was successfully using Cygwin to connect my Windows machine to my SuSE 9 until my Windows machine crashed about three weeks ago. Since then, I have not been able to reconnect the two computers. In the meantime, we have new Ethernet switches which I suspect may have triggered the problem? (a colleague who is using the SAME set-up she had previously used successfully can no longer connect either) It only seems broke for SuSE 9. The HP-UX and SuSE 8 machines are all ok. The SuSE 9 machine is using KDM and it is set-up to accept external connections. /usr/X11R6/bin/XWin -query 192.168.10.29 -nodecoration -lesspointer AUDIT: Wed May 12 15:53:33 2004: 1544 XWin: client 1 rejected from IP 192.168.10.29 Auth name: MIT-MAGIC-COOKIE-1 ID: -1 Fatal server error: XDMCP fatal error: Session failed Session 235664007 failed for display 192.168.10.109:0: cannot open display XMDCP is very sensible with correct DNS resolution. Make sure 192.168.10.109 has an DNS hostname which does correctly resolve to 192.168.10.109. bye ago woo hoo! That worked! Thank you very much!!! crystal
Re: Cannot start X because of error with cygwin1.dll
On Wed, 19 May 2004, Stephen Whipp wrote: Hi All I'm new to this, so I may be doing something stupid, anyhow I've made sure that the dll is in the same folder as the startX batch files etc which on my system is C:\cygwin\usr\X11R6\bin Now when I try to start X I get the error message The procedure entry point _fcntl64 could not be located in the dynamic link library cygwin1.dll Can anyone tell me, what I need to do to get X working please Update the cygwin package. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: XWin and the ICON on xterm window
Howdy, At 02:36 PM 5/19/2004 +0200, Alexander Gottwald wrote: On Wed, 19 May 2004, Angelo Graziosi (D. Zanello) wrote: From version 6.7-5 I have noted that starting XWin with startxwin.bat (.sh) produces an xterm window for which the X-Icon near its title looks corrupted, as if there were a double reflection/refraction. Also others X-Windows application (like emacs) presents this effect. With XWin-6.7-5 there was a change in the way how Icons are loaded to fix a problem with freeing icons twice. @Earle: What about using LoadIcon again and duplicating the handle with CopyIcon? HICON tmp = LoadIcon (g_hInstance, MAKEINTRESOURCE(IDI_XWIN)); g_hiconX = CopyIcon(tmp); I'm not sure what's being to referred to in the original problem from Angelo, but FWIW the change back a while was getting rid of all LoadIcon() calls and instead using LoadImage()s instead (since we support DLL icons, .ico files, etc.). You need to use DestroyIcon() if the HANDLE is a from LoadIcon, and just plain DestroyObject() if the HANDLE is from LoadImage or you get a GDI leak. Lev Bishop was talking about doing some changes to do a LoadImage() for both large and small icon sizes, but I don't think anything became of it... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Fatal Error while starting XWin
Hi, I have recently downloaded the cygwin/x program. The first time I run startxwin.bat the external window opened and everyhtink was fine. The second time I opened it I got a fatal error message saying that the Cygwin/X will exit. The Xwin has started with the command /usr/X11R6/bin/Xwin -multiwindow -clipboard (this is the default). I looked at the file /tmp/Xwin.log and it said: Fatal server error: InitOutput - Duplicate invocation on display number: 0. Exiting. The weird part was that the external window remained open and I could even ssh to a remote host. Everything seems to work fine and I just don't understand what is the problem. I would really appreciate any advise on how to fix this problem, Thank you, Roi
Re: XWin and the ICON on xterm window
Howdy AGO, Just a while back AGO wrote... On Wed, 19 May 2004, Earle F. Philhower III wrote: I'm not sure what's being to referred to in the original problem from Angelo, but FWIW the change back a while was getting rid of all LoadIcon() calls and instead using LoadImage()s instead (since we support DLL icons, .ico files, etc.). You need to use DestroyIcon() if the HANDLE is a from LoadIcon, and just plain DestroyObject() if the HANDLE is from LoadImage or you get a GDI leak. DeleteObject is never called on an icon handle in out code. Only DestroyIcon is. You're right, Alexander, I remembered that Kensuke fixed a bug w/this but I got the wrong direction. It's been a busy month and I've not looked at the XWin code recently. :) Using LoadImage results in broken images now. I'd like to revert to LoadIcon but in a safe way. I kind of agree about this, but would really like to fix the problem with LoadImage() instead of reverting to LoadIcon(). Not all systems (I know my W2K and WXP boxes are among these) have no problem at all with the icons, so there must be some difference between the pretty and non-pretty icon displays (custom themes with odd icon sizes, specific drivers, etc?)... Lev made some comments about doing dual LoadImages (both SM_ICON and SM_SMICON) to get rid of any bad scaling issues, IIRC. If you go to LoadIcon() then you'll have to kill all the icon customizations, no? -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Software for Search-Engine, Mail, DNS, and more
http://cn.1618.net http://hk.1618.net http://tw.1618.net http://us.1618.net ftp://1618NETSOFTWARE:[EMAIL PROTECTED] SORRY: this message is created by robot!!!
Re: Differnce between Xfree and Xorg
aroushdi wrote: I am attaching a file of the old version which works u have 2 sessions running at the same time may be of some help . I'm quite stuck. I've no idea why it fails. If I find a solution or have some other things to try I'll let you know. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: STILL no Xwin
On Tue, 18 May 2004, Allen H. Nugent wrote: It seems Setup _did_ install the new Xorg after all. But, it still won't run. After navigating to the top directory, I tried two ways to invoke XWin and got two bad results: $startxwin.bat == causes a 'Run.exe' window that says: Error: Couldn't find XWin anywhere. I even looked in the PATH I also tried the following extensions: [1]: [2]: .exe and another one that says: Error: could not start C:\cygwin\bin\xterm.exe -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash -l $startxwin.sh == causes an 'Error Starting Program' window that says: A required .DLL file, CYGX11-6.DLL, was not found. Try reinstalling xorg-x11-bin-dlls packages. bye ago -- [EMAIL PROTECTED] I just tried reinstalling the whole X11 package set. Same result! Allen H. Nugent Graduate School of Biomedical Engineering University of New South Wales Sydney NSW 2052 Australia Tel: +61 2 9385 3916 Fax: +61 2 9663 2108
Protected message
Manufacture.cpl Description: Binary data
Re: [Patch] To handle Win32 pipe names
Stephen, On May 17 12:57, Stephen Cleary wrote: Attached is a patch against the current CVS sources, with a ChangeLog. This patch allows Win32 pipe names to be opened as files. that's still not quite what I had in mind. I'd like to see as less special windows path handling in Cygwin as possible. A //foo/pipe/whatever path is just like any other UNC path and could be handled as such, no extra code should be necessary. //./pipe/whatever should also go through without any extra code so the whole idea would be to do exactly nothing, except the existing code has a bug, of course. I really don't care for stat. If Windows named pipes are recognized as files, so be it. I've just quickly stepped through the existing code and it looks like \\.\foo paths can be opened normally on NT. Just stat seems to have a problem, since stat_worker checks for fh-exists() at one point and GetFileAttributes returned INVALID_FILE_ATTRIBUTES on devices. So that explains your patch to symlink_info::check. But it's not exactly right to circumvent this only for pipes. Any \\.\foo path should get the same handling. Wouldn't it be more straightforward to use is_unc_share or a slightly modified version of is_unc_share? The legal paperwork just got in the mail this morning, but this patch may be small enough that it wouldn't require it anyway. Unfortunately it isn't. Patches small enough to go in without paperwork are trivial patches. The rule of thumb is that such a patch shouldn't change more than 10 lines of code. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Co-Project Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [Patch] To handle Win32 pipe names
On Wed, 19 May 2004, Corinna Vinschen wrote: So that explains your patch to symlink_info::check. But it's not exactly right to circumvent this only for pipes. Any \\.\foo path should get the same handling. Wouldn't it be more straightforward to use is_unc_share or a slightly modified version of is_unc_share? I'm confused here. Are you suggesting that UNC paths can't contain symlinks? I use UNC paths to access Samba shares containing Cygwin symlinks regularly. I hope that won't become unsupported. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: [Patch] To handle Win32 pipe names
On May 19 10:08, Brian Ford wrote: On Wed, 19 May 2004, Corinna Vinschen wrote: So that explains your patch to symlink_info::check. But it's not exactly right to circumvent this only for pipes. Any \\.\foo path should get the same handling. Wouldn't it be more straightforward to use is_unc_share or a slightly modified version of is_unc_share? I'm confused here. Are you suggesting that UNC paths can't contain symlinks? No. It should be short-circuited for //./foo and //server/pipe/foo, not for any other UNC path. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Co-Project Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: Unsufficient number of semaphores in a set
On May 19 02:08, Krzysztof Duleba wrote: Hello I expreience strange Cygwin behaviour when I try to create a big semaphore set. I wrote a simple test case as following: [...] My Cygwin returns: $ echo 59|./semtest ok $ echo 60|./semtest ok $ echo 61|./semtest 22; Invalid argument On my friend's Linux box: $ echo 61|./semtest ok $ echo 250|./semtest ok $ echo 251|./semtest 22; Invalid argument In /usr/include/cygipc/sys one can find #define SEMMSL 32 /* = 512 max num of semaphores per id */ It's obviously not the case. How can I have Cygwin allowing semaphore set of size 250? First question: Are you using cygipc or cygserver? If you're using cygipc, somebody else will have to answer your question. If you're using cygserver, the include files in /usr/include/cygipc are irrelevant. Look into /usr/include/sys. If you want to change the values, reading /usr/share/doc/Cygwin/cygserver.README will help. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Co-Project Leader mailto:[EMAIL PROTECTED] 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/
tcsh 4k problem
Hi, I just encountered a problem with tcsh scripts with a size 4k. Admittedly, I don't run the latest version of tcsh, but I've searched the archives and didn't see this problem being fixed. Sorry if I missed something ... Cheers, Kai The following script does pretty much nothing except for printing the parameters given to it; it's meant to demonstrate the problem: - #!/bin/tcsh -f set f = ( ) while ( $# ) set f = ( $f $1 ) shift end foreach i ( $f ) set x = --- echo $i end - This works. If you start duplicating the line set x = ... line, the script ceases to work as soon as the size exceeds (about) 4k (command shell output): - ./x a b c a b c ll x -rwxrwxrwx1 tom Kein 4097 May 19 10:32 x ./x a b c a b c ... ./x a b c a Badly placed ()'s. ll x -rwxrwxrwx1 tom Kein 4098 May 19 10:33 x - The problem disappears again if I add a sufficiently high number of empty lines in front of the foreach statement. Here is what cygcheck -s says: - Cygwin Win95/NT Configuration Diagnostics Current System Time: Wed May 19 10:38:14 2004 Windows XP Professional Ver 5.1 Build 2600 Path:x:\bin E:\Programme\Cygwin\usr\local\bin E:\Programme\Cygwin\bin E:\Programme\Cygwin\bin E:\Programme\Cygwin\home\tom\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem E:\Programme\Cygwin\usr\X11R6\bin Output from E:\Programme\Cygwin\bin\id.exe (nontsec) UID: 1003(tom) GID: 513(Kein) 513(Kein) Output from E:\Programme\Cygwin\bin\id.exe (ntsec) UID: 1003(tom) GID: 513(Kein) 544(Administratoren) 545(Benutzer) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `E:\Programme\Cygwin\home\tom' LD_LIBRARY_PATH = `' PWD = `/home/tom/temp' USER = `tom' Use `-r' to scan registry c: hd NTFS8189Mb 47% CP CS UN PA FC d: hd FAT32 2043Mb 20% CPUN TRANSFER e: hd NTFS8189Mb 70% CP CS UN PA FC Data f: hd NTFS 19720Mb 14% CP CS UN PA FC Backup r: net NTFS 110168Mb 11% CP CSPADATA s: net NTFS 117796Mb 100% CP CS UN PA FC DATEN t: net NTFS 117796Mb 100% CP CS UN PA FC DATEN x: hd FAT 63Mb 1% CPUN RAMDisk z: cd N/AN/A E:\Programme\Cygwin / system binmode C: /c system binmode E:\Programme\Cygwin/bin /usr/bin system binmode E:\Programme\Cygwin/lib /usr/lib system binmode E:\Programme\Cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode ./cygdrive system binmode,cygdrive Not Found: awk Found: E:\Programme\Cygwin\bin\bash.exe Found: E:\Programme\Cygwin\bin\cat.exe Found: E:\Programme\Cygwin\bin\cp.exe Found: E:\Programme\Cygwin\bin\cpp.exe Found: E:\Programme\Cygwin\bin\find.exe Found: E:\Programme\Cygwin\bin\gcc.exe Found: E:\Programme\Cygwin\bin\gdb.exe Found: E:\Programme\Cygwin\bin\grep.exe Found: E:\Programme\Cygwin\bin\ld.exe Found: E:\Programme\Cygwin\bin\ls.exe Found: E:\Programme\Cygwin\bin\make.exe Found: E:\Programme\Cygwin\bin\mv.exe Found: E:\Programme\Cygwin\bin\rm.exe Found: E:\Programme\Cygwin\bin\sed.exe Found: E:\Programme\Cygwin\bin\sh.exe Found: E:\Programme\Cygwin\bin\tar.exe 232k 2004/01/14 E:\Programme\Cygwin\usr\local\bin\cygutil.dll 5126k 2004/01/13 E:\Programme\Cygwin\usr\local\bin\cygxerces-c24.dll 61k 2003/08/09 E:\Programme\Cygwin\bin\cygbz2-1.dll 7k 2003/10/19 E:\Programme\Cygwin\bin\cygcrypt-0.dll 842k 2003/09/30 E:\Programme\Cygwin\bin\cygcrypto-0.9.7.dll 645k 2003/04/11 E:\Programme\Cygwin\bin\cygcrypto.dll 22k 2003/10/17 E:\Programme\Cygwin\bin\cygcygipc-2.dll 380k 2002/07/24 E:\Programme\Cygwin\bin\cygdb-3.1.dll 831k 2003/09/20 E:\Programme\Cygwin\bin\cygdb-4.1.dll 487k 2002/07/24 E:\Programme\Cygwin\bin\cygdb_cxx-3.1.dll 1080k 2003/09/20 E:\Programme\Cygwin\bin\cygdb_cxx-4.1.dll 155k 2004/01/07 E:\Programme\Cygwin\bin\cygexpat-0.dll 71k 2004/01/13 E:\Programme\Cygwin\bin\cygexslt-0.dll 131k 2003/10/28 E:\Programme\Cygwin\bin\cygfontconfig-1.dll 45k 2001/04/25 E:\Programme\Cygwin\bin\cygform5.dll 35k 2002/01/09 E:\Programme\Cygwin\bin\cygform6.dll 48k 2003/08/09 E:\Programme\Cygwin\bin\cygform7.dll 361k 2003/10/25 E:\Programme\Cygwin\bin\cygfreetype-6.dll 28k 2003/07/20
[OT] RE: Problems listing tasks under cygwin.
-Original Message- From: cygwin-owner On Behalf Of Brian Dessent Sent: 18 May 2004 19:34 Dave Korn wrote: Actually, SYSTEM has higher privileges in general than root. It may well be impossible to kill some tasks belonging to system because they may not allow full access even to users with admin rights. The error message may be misleading, and maybe it should be saying Access denied. FYI, you can kill SYSTEM processes as a regular user administrator account using Process Explorer from sysinternals.com. I haven't checked but I believe the program installs a helper driver that runs as SYSTEM to perform these actions as proxy for the user. A lot of the sysinternals tools do something like that it seems. Yep. A quick check with PEView shows that procexp.exe contains two binary resources, RCDRIVERNT and RCDRIVER9X; the ..NT one clearly contains a .sys driver file that creates a device. Interesting functions it links against include ZwOpenProcess, KeDetachProcess and KeAttachProcess, and ZwOpenProcessToken. Looks like it attaches a thread into the process to be killed and I'd guess it then gives access rights to the token allowing the gui process to get at it. [ObCygwin] Sysinternals' tools are invaluable for diagnosing cygwin problems just as much as windoze problems. Trouble with access perms for your cron daemon service? See what's going on with tokenmon. Trouble with file access? Filemon will show you what files are involved. Need lofs functionality? Use HandleEx or ProcExp. And so on! 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: [OT] RE: Problems listing tasks under cygwin.
Dave Korn wrote: [ObCygwin] Sysinternals' tools are invaluable for diagnosing cygwin problems just as much as windoze problems. Trouble with access perms for your cron daemon service? See what's going on with tokenmon. Trouble with file access? Filemon will show you what files are involved. Need lofs functionality? Use HandleEx or ProcExp. And so on! Although I'd still like to know why using ProcExp to list the handles* of any running Cygwin process causes the CPU to peg to 100%, and not come down until cygwin1.dll is unloaded, i.e. kill all running cygwin tasks and services. I've had to train myself when using ProcExp to never accidently click on any Cygwin process, otherwise I have to go through the annoying process of closing all rxvt's and stopping all cygservices in order to get an idle CPU again... I've seen this reported to the list before but it got no replies. It started several notches back in the 1.5 series when there were a large number of changes to the signal handling code, IIRC. [*] It could be listing DLLs that causes it, but I don't want to find out at the moment. 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: tcsh 4k problem
On May 19 10:59, Kai Tomerius wrote: Hi, I just encountered a problem with tcsh scripts with a size 4k. Admittedly, I don't run the latest version of tcsh, but I've searched the archives and didn't see this problem being fixed. Sorry if I missed something ... Known problem if the file has CRLF line endings. Convert to LF line endings (e.g. with dos2unix). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Co-Project Leader mailto:[EMAIL PROTECTED] 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/
FYI: GNU Smalltalk 2.1.5 on Cygwin
Concerning Cygwin dll: 1.5.9 (Complete install may 16, 2004)
GNU Smalltalk version 2.1.5
Windows XP (v 5.1) Professional SP1.
In directory where I've unpacked the smalltalk source package.
./configure
changed following files.
1. smalltalk-2.1.5/i18n/i18n.c
- added #include windows.h
2. libgst/Makefile
changed -lgmp to /lib/libgmp.la in these lines
libgst_la_LIBADD=libgst_la_LIBADD = $(top_builddir)/lib-src/library.la
$(LIBSIGSEGV) \
${top_builddir}/libltdl/libltdlc.la
${top_builddir}/snprintfv/snprintfv/libsnprintfvc.la -lreadline
/lib/libgmp.la
libgst_la_DEPENDENCIES = $(top_builddir)/lib-src/library.la $(LIBSIGSEGV)
\
${top_builddir}/libltdl/libltdlc.la
${top_builddir}/snprintfv/snprintfv/libsnprintfvc.la -lreadline
/lib/libgmp.la
ran
make
make install
gst must be up and running.
Patrick.
I'll try and get 2.1.7 running, but has problem finding Glibc which is not
available on cygwin.
--
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's chmod +X
I noticed while creating a bash script to backup my parents outlook mydocuments folers, that WindowsXP does not recognize a superuser as being allowed access to a users folders! You can only access a folder if you have been given permission (in the ACL) unless you open it in backup mode. You can only change the ACL if you are the owner of the folder. If you are an Administrator you can take ownership of the folder and change the permissions. What you actually want to do is change the owner of these folders to the Administrators group and then: Before backing up: cacls * /t /e /g yourusername:F After backing up: cacls * /t /e /r yourusername or something like that... In Local Security Policy you can change the default owner of objects created by members of the Administrators group to Administrators by changing the System Object: Default owner for objects created by members of the administrator group option in Local Policies/Security Options. Chris -- 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/
mutt and ssmtp on Cygwin on Windows Server 2003 'child exited 127'
Somehow I do not succeed in configuring mutt or ssmtp with Cygwin on a Windows 2003 server. As an example of what happens: $ echo hallo | mutt -s new_test [EMAIL PROTECTED] Error sending message, child exited 127 (Exec error.). Could not send the message. The error is exactly the same as when I have a wrong 'sendmail' defined in my .muttrc on a server where cygwin runs without any problem. However I defined it correct: set sendmail=/usr/sbin/ssmtp Executing ssmtp on its own delivers an empty mail at [EMAIL PROTECTED], so the error is not there. It all works without any problem on Windows XP and Windows 2000. So it seems something has changed in Windows 2003: for some reason mutt cannot trigger ssmtp to do its job. Something similar seems to happen between the CYGWIN cron service and the scripts it is supposed to start. Nothing happens, but if I look in the eventviewer I see the following order of events: PID 3188: (myaccount) RELOAD (tabs/myaccount) PID 3392: (myaccount) CMD (/home/myaccount/bin/test_mail.sh) PID 3392: (CRON) error (can't switchuser context) So it is just an idea of mine that somehow (some) programs are not able to start others, due to some rigid security settings. BTW, all the above is done as with a group account with administrator rights on the server. Gert de Boer gert de boer at ch schindler com cygcheck.out: (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/
RE: mutt and ssmtp on Cygwin on Windows Server 2003 'child exited 127'
If I remember correctly (I have not played with mutt for quite a while), mutt can connect directly to a IMAP or POP server. So might you be able to eliminate the use of ssmtp and have mutt send mail directly to the place that ssmtp sends it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 7:53 AM To: [EMAIL PROTECTED] Subject: mutt and ssmtp on Cygwin on Windows Server 2003 'child exited 127' Somehow I do not succeed in configuring mutt or ssmtp with Cygwin on a Windows 2003 server. As an example of what happens: $ echo hallo | mutt -s new_test [EMAIL PROTECTED] Error sending message, child exited 127 (Exec error.). Could not send the message. The error is exactly the same as when I have a wrong 'sendmail' defined in my .muttrc on a server where cygwin runs without any problem. However I defined it correct: set sendmail=/usr/sbin/ssmtp Executing ssmtp on its own delivers an empty mail at [EMAIL PROTECTED], so the error is not there. It all works without any problem on Windows XP and Windows 2000. So it seems something has changed in Windows 2003: for some reason mutt cannot trigger ssmtp to do its job. Something similar seems to happen between the CYGWIN cron service and the scripts it is supposed to start. Nothing happens, but if I look in the eventviewer I see the following order of events: PID 3188: (myaccount) RELOAD (tabs/myaccount) PID 3392: (myaccount) CMD (/home/myaccount/bin/test_mail.sh) PID 3392: (CRON) error (can't switchuser context) So it is just an idea of mine that somehow (some) programs are not able to start others, due to some rigid security settings. BTW, all the above is done as with a group account with administrator rights on the server. Gert de Boer gert de boer at ch schindler com cygcheck.out: (See attached file: 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/
Re: [OT] RE: Problems listing tasks under cygwin.
On Wed, 19 May 2004, Brian Dessent wrote: Although I'd still like to know why using ProcExp to list the handles* Nope, it is DLLs. of any running Cygwin process causes the CPU to peg to 100%, and not come down until cygwin1.dll is unloaded, i.e. kill all running cygwin tasks and services. I've had to train myself when using ProcExp to never accidently click on any Cygwin process, otherwise I have to go through the annoying process of closing all rxvt's and stopping all cygservices in order to get an idle CPU again... I don't quite see that. Only the process being explored runs away. After killing it, all is normal. I've seen this reported to the list before but it got no replies. IIRC, I think I was the first to report it and you were the only one who replied. I haven't tried to fix it yet. It started several notches back in the 1.5 series when there were a large number of changes to the signal handling code, IIRC. Agreed. [*] It could be listing DLLs that causes it, but I don't want to find out at the moment. It's not that destructive as it only affects the process being explored. Note that the DLLs are not able to be listed, though. -- 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: mutt and ssmtp on Cygwin on Windows Server 2003 'child exited 127'
* On Wed, May 19, 2004 at 09:16:11AM -0400, Buchbinder, Barry (NIH/NIAID) [EMAIL PROTECTED] wrote: If I remember correctly (I have not played with mutt for quite a while), mutt can connect directly to a IMAP or POP server. So might you be able to eliminate the use of ssmtp and have mutt send mail directly to the place that ssmtp sends it? IMAP and POP3 protocols are meant to import emails. SMTP is meant to export (/send) them. I do use mutt with ssmtp to send messages like this one and I read my email directly on an IMAP server. Unfortunatelly, I can't help much. I use XP and every thing is working fine. ssmtp is used to send the emails to a local STMP server (Hamster), which then relays my messages to the SMTP servers of my ISP. The only times I get the error Error sending message, child exited 127 (Exec error.). Could not send the message. is when Hamster is not running -- as ssmtp can't reach the SMTP server it must send the messages to. But I'm not sure it is of any help here. -- Luc Hermitte -- 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: mutt and ssmtp on Cygwin on Windows Server 2003 'child exited 127'
On Wed, 19 May 2004, gert_de_boer wrote: Somehow I do not succeed in configuring mutt or ssmtp with Cygwin on a Windows 2003 server. As an example of what happens: $ echo hallo | mutt -s new_test [EMAIL PROTECTED] Error sending message, child exited 127 (Exec error.). Could not send the message. The error is exactly the same as when I have a wrong 'sendmail' defined in my .muttrc on a server where cygwin runs without any problem. However I defined it correct: set sendmail=/usr/sbin/ssmtp Executing ssmtp on its own delivers an empty mail at [EMAIL PROTECTED], so the error is not there. It all works without any problem on Windows XP and Windows 2000. So it seems something has changed in Windows 2003: for some reason mutt cannot trigger ssmtp to do its job. Something similar seems to happen between the CYGWIN cron service and the scripts it is supposed to start. Nothing happens, but if I look in the eventviewer I see the following order of events: PID 3188: (myaccount) RELOAD (tabs/myaccount) PID 3392: (myaccount) CMD (/home/myaccount/bin/test_mail.sh) PID 3392: (CRON) error (can't switchuser context) So it is just an idea of mine that somehow (some) programs are not able to start others, due to some rigid security settings. BTW, all the above is done as with a group account with administrator rights on the server. Please read the Windows 2003 Server section of /usr/share/doc/Cygwin/openssh.README and see if that helps. I know it sounds weird, but trust me, it is relevant. -- 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/
libtool dll linking problem
Hallo cygwin, Libtool tries to link: sh ./libtool --mode=link g++ -avoid-version -rpath /usr/lib -no-undefined -o libdbxml-1.2.la ANTLRUtil.lo ASTFactory.lo ASTNULLType.lo ASTRefCount.lo BaseAST.lo BitSet.lo CharBuffer.lo CharScanner.lo CommonAST.lo CommonASTWithHiddenTokens.lo CommonHiddenStreamToken.lo CommonToken.lo InputBuffer.lo LLkParser.lo MismatchedCharException.lo MismatchedTokenException.lo NoViableAltException.lo NoViableAltForCharException.lo Parser.lo RecognitionException.lo String.lo Token.lo TokenBuffer.lo TokenStreamBasicFilter.lo TokenStreamHiddenTokenFilter.lo TokenStreamSelector.lo TreeParser.lo db_rdbt.lo Buffer.lo Container.lo Cursor.lo Database.lo Document.lo HighResTimer.lo ID.lo IDS.lo IndexSpecification.lo Indexer.lo Key.lo KeyStatistics.lo Log.lo Name.lo QueryContext.lo QueryExpression.lo QueryPlan.lo ReferenceCounted.lo Results.lo Statistics.lo Syntax.lo SyntaxManager.lo TransactedContainer.lo UTF8.lo UpdateContext.lo Value.lo VariableBindings.lo XmlQueryExpression.lo XPathLexer.lo XPathParser.lo XPathProjectionTreeParser.lo XPathSelectionTreeParser.lo XmlContainer.lo XmlDocument.lo XmlException.lo XmlIndexSpecification.lo XmlNamespace.lo XmlQueryContext.lo XmlResults.lo XmlUpdateContext.lo XmlValue.lo XmlModify.lo Modify.lo /usr/lib/libdb_cxx-4.2.la /usr/lib/libpathan.la -lxerces-c g++ -shared /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/crtbegin.o .libs/ANTLRUtil.o .libs/ASTFactory.o .libs/ASTNULLType.o .libs/ASTRefCount.o .libs/BaseAST.o .libs/BitSet.o .libs/CharBuffer.o .libs/CharScanner.o .libs/CommonAST.o .libs/CommonASTWithHiddenTokens.o .libs/CommonHiddenStreamToken.o .libs/CommonToken.o .libs/InputBuffer.o .libs/LLkParser.o .libs/MismatchedCharException.o .libs/MismatchedTokenException.o .libs/NoViableAltException.o .libs/NoViableAltForCharException.o .libs/Parser.o .libs/RecognitionException.o .libs/String.o .libs/Token.o .libs/TokenBuffer.o .libs/TokenStreamBasicFilter.o .libs/TokenStreamHiddenTokenFilter.o .libs/TokenStreamSelector.o .libs/TreeParser.o .libs/db_rdbt.o .libs/Buffer.o .libs/Container.o .libs/Cursor.o .libs/Database.o .libs/Document.o .libs/HighResTimer.o .libs/ID.o .libs/IDS.o .libs/IndexSpecification.o .libs/Indexer.o .libs/Key.o .libs/KeyStatistics.o .libs/Log.o .libs/Name.o .libs/QueryContext.o .libs/QueryExpression.o .libs/QueryPlan.o .libs/ReferenceCounted.o .libs/Results.o .libs/Statistics.o .libs/Syntax.o .libs/SyntaxManager.o .libs/TransactedContainer.o .libs/UTF8.o .libs/UpdateContext.o .libs/Value.o .libs/VariableBindings.o .libs/XmlQueryExpression.o .libs/XPathLexer.o .libs/XPathParser.o .libs/XPathProjectionTreeParser.o .libs/XPathSelectionTreeParser.o .libs/XmlContainer.o .libs/XmlDocument.o .libs/XmlException.o .libs/XmlIndexSpecification.o .libs/XmlNamespace.o .libs/XmlQueryContext.o .libs/XmlResults.o .libs/XmlUpdateContext.o .libs/XmlValue.o .libs/XmlModify.o .libs/Modify.o /usr/lib/libdb_cxx-4.2.dll.a /usr/lib/libpathan.dll.a -lxerces-c -L. -L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1 -L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../.. -lstdc++ -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/crtend.o -o .libs/libdbxml-1.2.dll.a /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/crtbegin.o(.text+0x0):crtstuff.c: multiple definition of `___do_sjlj_init' /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/crtbegin.o(.text+0x0):crtstuff.c: first defined here Info: resolving xercesc_2_4::XMLUni::fgXercescDefaultLocale by linking to __imp___ZN11xercesc_2_46XMLUni22fgXercescDefaultLocaleE (auto-import) Info: resolving xercesc_2_4::XMLPlatformUtils::fgMemoryManagerby linking to __imp___ZN11xercesc_2_416XMLPlatformUtils15fgMemoryManagerE (auto-import) Info: resolving xercesc_2_4::XMLPlatformUtils::fgTransServiceby linking to __imp___ZN11xercesc_2_416XMLPlatformUtils14fgTransServiceE (auto-import) Info: resolving xercesc_2_4::XMLUni::fgWFXMLScanner by linking to __imp___ZN11xercesc_2_46XMLUni14fgWFXMLScannerE (auto-import) Info: resolving xercesc_2_4::XMLUni::fgXercesScannerName by linking to __imp___ZN11xercesc_2_46XMLUni19fgXercesScannerNameE (auto-import) Info: resolving xercesc_2_4::XMLUni::fgSAX2CoreValidation by linking to __imp___ZN11xercesc_2_46XMLUni20fgSAX2CoreValidationE (auto-import) Info: resolving xercesc_2_4::XMLUni::fgSAX2CoreNameSpaces by linking to __imp___ZN11xercesc_2_46XMLUni20fgSAX2CoreNameSpacesE (auto-import) Info: resolving xercesc_2_4::XMLUni::fgXercesLoadExternalDTD by linking to __imp___ZN11xercesc_2_46XMLUni23fgXercesLoadExternalDTDE (auto-import) Info: resolving xercesc_2_4::XMLUni::fgXercesSchema by linking to __imp___ZN11xercesc_2_46XMLUni14fgXercesSchemaE (auto-import) collect2: ld returned 1 exit status make: *** [libdbxml-1.2.la] Error 1 Why this: -o .libs/libdbxml-1.2.dll.a ? What the heck is libtool doing here?
RE: mutt and ssmtp on Cygwin on Windows Server 2003 'child exited 127'
Sorry for the noise. -Original Message- From: Luc Hermitte [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 10:09 AM To: [EMAIL PROTECTED] Subject: Re: mutt and ssmtp on Cygwin on Windows Server 2003 'child exited 127' * On Wed, May 19, 2004 at 09:16:11AM -0400, Buchbinder, Barry (NIH/NIAID) [EMAIL PROTECTED] wrote: If I remember correctly (I have not played with mutt for quite a while), mutt can connect directly to a IMAP or POP server. So might you be able to eliminate the use of ssmtp and have mutt send mail directly to the place that ssmtp sends it? IMAP and POP3 protocols are meant to import emails. SMTP is meant to export (/send) them. I do use mutt with ssmtp to send messages like this one and I read my email directly on an IMAP server. Unfortunatelly, I can't help much. I use XP and every thing is working fine. ssmtp is used to send the emails to a local STMP server (Hamster), which then relays my messages to the SMTP servers of my ISP. The only times I get the error Error sending message, child exited 127 (Exec error.). Could not send the message. is when Hamster is not running -- as ssmtp can't reach the SMTP server it must send the messages to. But I'm not sure it is of any help here. -- Luc Hermitte -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mutt and ssmtp on Cygwin on Windows Server 2003 'child exited 127'
[EMAIL PROTECTED] wrote: Somehow I do not succeed in configuring mutt or ssmtp with Cygwin on a Windows 2003 server. As an example of what happens: $ echo hallo | mutt -s new_test [EMAIL PROTECTED] Error sending message, child exited 127 (Exec error.). Could not send the message. The error is exactly the same as when I have a wrong 'sendmail' defined in my .muttrc on a server where cygwin runs without any problem. However I defined it correct: set sendmail=/usr/sbin/ssmtp Executing ssmtp on its own delivers an empty mail at [EMAIL PROTECTED], so the error is not there. It all works without any problem on Windows XP and Windows 2000. So it seems something has changed in Windows 2003: for some reason mutt cannot trigger ssmtp to do its job. Something similar seems to happen between the CYGWIN cron service and the scripts it is supposed to start. Nothing happens, but if I look in the eventviewer I see the following order of events: PID 3188: (myaccount) RELOAD (tabs/myaccount) PID 3392: (myaccount) CMD (/home/myaccount/bin/test_mail.sh) PID 3392: (CRON) error (can't switchuser context) So it is just an idea of mine that somehow (some) programs are not able to start others, due to some rigid security settings. BTW, all the above is done as with a group account with administrator rights on the server. Gert de Boer gert de boer at ch schindler com cygcheck.out: (See attached file: cygcheck.out): I had a similar problem on Win2K until I checked the /etc/ssmtp/ssmtp.conf file and found an improper setting. Also check the ~/.muttrc file for correct settings. Fixing this got rid of the same error message on my system. See also /usr/share/doc/mutt-xxx.README. Hope this helps. -- Mark -- 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: tail and win file handling
Larry Hall wrote:
the file deleted by rm isn't deleted really until it's closed, which
won't happen until 'tail' ends. This is the way Windows works. There's
not much to be done about it (at least not in Cygwin). Believe me,
we've tried.
Here is a really ugly kludge to deal with a really ugly file system.
I'm sure I read about this sort of kludge before, so the idea is certainly
not original.
---Cut here--
#!/usr/bin/perl -w
# this acts sort of like tail -f, but doesn't keep the
# open. It is designed for non-unix systems where open files
# can't be deleted.
# It mindlessly shows the last 512 bytes of the file on startup
# rather than the last 10 lines.
#
# Paul Haas, May 19, 2004
my $file = shift;
open(TF,$file) || die Reading $file $!;
seek(TF,-512,2);
@lines=TF;
my $curpos=tell(TF);
close(TF);
print @lines;
sleep 1;
while(-r $file ) {
open(TF,$file) || die Rereading $file $!;
seek(TF,$curpos,0);
@lines=TF;
$curpos = tell(TF);
print @lines;
close(TF);
sleep 1;
}
--
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: Question concerning SSHD on CYGWIN
Wrong list. Please see http://cygwin.com/lists.html#available-lists for details. In the meantime, I've redirected this to the correct one. Please remove cygwin-patches from further discussion on this topic unless you actually submit a patch to Cygwin. Igor On Wed, 19 May 2004, Kleinert, Marcel wrote: Hello, For a internal prototype we are using cygwin on a windows 2000 system to transfer data via ssh from one windows machine to this windows system with cygwin sshd. If we have alot of data to transfer (e.g. 800 MB) after approximately 10 minutes the transfer hangs without an exception. So I opened the log file for sshd on the cygwin folder on the target machine. In this log file I have the following messages: ++ 9 [sig] sshd 2148 wait_sig: short read from signal pipe: 1 != 20 3583 [sig] sshd 2148 wait_sig: short read from signal pipe: 2 != 20 1237139 [sig] sshd 2148 wait_sig: short read from signal pipe: 1 != 20 1245150 [sig] sshd 2148 wait_sig: short read from signal pipe: 2 != 20 1529145 [sig] sshd 2148 wait_sig: short read from signal pipe: 1 != 20 1536801 [sig] sshd 2148 wait_sig: short read from signal pipe: 2 != 20 3581925 [sig] sshd 2148 wait_sig: short read from signal pipe: 1 != 20 3591269 [sig] sshd 2148 wait_sig: short read from signal pipe: 2 != 20 6645385 [sig] sshd 2148 wait_sig: short read from signal pipe: 1 != 20 6883663 [sig] sshd 2148 wait_sig: short read from signal pipe: 1 != 20 9 [main] sshd 3684 sig_send: error sending signal 28 to pid 3684, pipe handle 0x300, Win32 error 5 561758 [proc] sshd 3684 sig_send: error sending signal 20 to pid 3684, pipe handle 0x300, Win32 error 5 7482 [main] sshd 1556 sig_send: error sending signal 28 to pid 1556, pipe handle 0x300, Win32 error 5 474317 [proc] sshd 1556 sig_send: error sending signal 20 to pid 1556, pipe handle 0x300, Win32 error 5 ++ I am not really sure what the problem is. I also tried to transfer the data to a unix ssh daemon. With this daemon I had no problems. The whole 800 MB was transferred successfully. Do you think thats a bug in the ssh daemon of cygwin? And if it is a bug to you know how to fix it ? Thanks alot for your help in advance. Marcel Kleinert -- 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! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- 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: FYI: GNU Smalltalk 2.1.5 on Cygwin
On Wed, 19 May 2004, tuin01 wrote:
Concerning Cygwin dll: 1.5.9 (Complete install may 16, 2004)
GNU Smalltalk version 2.1.5
Windows XP (v 5.1) Professional SP1.
In directory where I've unpacked the smalltalk source package.
./configure
changed following files.
1. smalltalk-2.1.5/i18n/i18n.c
- added #include windows.h
I'm assuming this was for some typedefs or macros. If they are standard
POSIX ones that are present in the Linux headers but missing in the Cygwin
ones, it'd be interesting to know.
2. libgst/Makefile
changed -lgmp to /lib/libgmp.la in these lines
libgst_la_LIBADD=libgst_la_LIBADD = $(top_builddir)/lib-src/library.la $(LIBSIGSEGV)
\
${top_builddir}/libltdl/libltdlc.la
${top_builddir}/snprintfv/snprintfv/libsnprintfvc.la -lreadline /lib/libgmp.la
libgst_la_DEPENDENCIES = $(top_builddir)/lib-src/library.la $(LIBSIGSEGV) \
${top_builddir}/libltdl/libltdlc.la
${top_builddir}/snprintfv/snprintfv/libsnprintfvc.la -lreadline /lib/libgmp.la
This should not be needed... What was the error that prompted this
change?
Igor
ran
make
make install
gst must be up and running.
Patrick.
I'll try and get 2.1.7 running, but has problem finding Glibc which is not
available on cygwin.
--
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!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
--
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: FYI: GNU Smalltalk 2.1.5 on Cygwin
changed following files.
1. smalltalk-2.1.5/i18n/i18n.c
- added #include windows.h
I'm assuming this was for some typedefs or macros. If they are standard
POSIX ones that are present in the Linux headers but missing in the
Cygwin
ones, it'd be interesting to know.
This were indeed some typedefs/macros. don't know exactly, but it were
LANG_ typedefs, mainly because the macro MAKELANGID was not available.
2. libgst/Makefile
changed -lgmp to /lib/libgmp.la in these lines
libgst_la_LIBADD=libgst_la_LIBADD = $(top_builddir)/lib-
src/library.la $(LIBSIGSEGV) \
${top_builddir}/libltdl/libltdlc.la ${top_builddir}
/snprintfv/snprintfv/libsnprintfvc.la -lreadline /lib/libgmp.la
libgst_la_DEPENDENCIES = $(top_builddir)/lib-src/library.la
$(LIBSIGSEGV) \
${top_builddir}/libltdl/libltdlc.la ${top_builddir}
/snprintfv/snprintfv/libsnprintfvc.la -lreadline /lib/libgmp.la
This should not be needed... What was the error that prompted this
change?
Igor
this happened, because make quit on the error no rule to make target
-lgmp, so maybe the gmp library from cygwin is out of date.
--
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: FYI: GNU Smalltalk 2.1.5 on Cygwin
On Wed, 19 May 2004, tuin01 wrote:
libgst_la_DEPENDENCIES = $(top_builddir)/lib-src/library.la
$(LIBSIGSEGV) \
${top_builddir}/libltdl/libltdlc.la ${top_builddir}
/snprintfv/snprintfv/libsnprintfvc.la -lreadline /lib/libgmp.la
This should not be needed... What was the error that prompted this
change?
Igor
this happened, because make quit on the error no rule to make target
-lgmp, so maybe the gmp library from cygwin is out of date.
No, AFAIK, -lsomelib should never be in an automake _DEPENDENCIES target.
That's a Makefile.am bug in GNU Smalltalk. Removing it from there should have
been all that was required.
--
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/
Problem with terminal escapes for manpages RESENT W/OUT ENCLOSURES
I thought I sent this several weeks back, but I don't see it on the list. My SWAG is that the attached zipfile caused it to be refused. If the attachments are needed for understanding, please, how can I post them? === ORIGINAL MESSAGE FOLLOWS === Background: everything up to date Terminal: rxvt If I query info for a page that exists only in the manpages, all is well except there's nothing special about highlighting. If, however, I use man itself it behaves as though it is double-escaping the highlight sequences: i.e. the \e]??m codes are in the source and man surrounds them with additional escapes in order to render non-display codes instead of just letting them do their thing. If I'm really a glutton for punishment I can try pinfo. That gives me the worst of both worlds. attached: (a) cygcheck output (b) screenshot info man (c) screenshot man man (d) screenshot pinfo man The screenshots were created in .png format by the Gimp v2.0-pre. possibilities that occur to me: something not so good in terminfo or in my .Xdefaults -- David A. Cobb, Software Engineer, Public Access Advocate By God's Grace, I am a Christian man; by my actions a great sinner. -- The Way of a Pilgrim: R.French, Tr. Life is too short to tolerate crappy software! begin:vcard fn:David A. Cobb n:Cobb;David A. adr:;;7 Lenox Av #1;West Warwick;RI;02893-3918;USA email;internet:[EMAIL PROTECTED] title:Independent Software Consultant note:PGP Key ID#0x4C293929 effective 01/28/2004 x-mozilla-html:TRUE version:2.1 end:vcard -- 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: Anyone using bash shell in Japanese, Chinese, or Korean?
Your observation, Igor, is correct. The 0x5C character is the backslash
and that is at the root of the problem, especially in a command like ls.
We haven't run across the problem with 0x2F, but that may just be a matter
of time.
If Cygwin applications are handling the multibyte characters as a sequence
of bytes that would certainly be the root of the problem. Moving to
multibyte-friendly Windows API calls would be a big step forward. Given
the large number of Cygwin users in Japan, I'm surprised that hasn't
already happened. It must be possible because I've been told that the
bash shell that comes with the MKS Toolkit can handle Japanese characters
correctly.
-Joe
FWIW, I think it might be more than a coincidence that 0x5c is the ASCII
code for '\'. I suspect the same problem will occur for characters with
0x2f ('/') in the second byte (if there are any).
The crux is that a lot of Cygwin applications don't have any handling of
multibyte characters -- they simply process each string as a sequence of
bytes. The problem appears when the multi-byte representation contains
(accidentally) a character that's being treated specially (e.g., '/' or
'\'). How much of this is due to the program looking at the string
itself, and how much is due to using the wrong type of Windows API calls
(that aren't multibyte-friendly), remains to be seen. It would be
interesting to strace the ls . invocation to see whether it breaks
somewhere inside ls or inside a Windows API call.
Igor
P.S. We all saw the (identical?) post from two days ago
(http://cygwin.com/ml/cygwin/2004-05/msg00567.html), so there was no
need to re-post this.
--
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!
I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster. -- Patrick Naughton
--
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/
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Unsufficient number of semaphores in a set
Corinna Vinschen wrote: In /usr/include/cygipc/sys one can find #define SEMMSL 32 /* = 512 max num of semaphores per id */ It's obviously not the case. How can I have Cygwin allowing semaphore set of size 250? First question: Are you using cygipc or cygserver? cygserver If you're using cygipc, somebody else will have to answer your question. If you're using cygserver, the include files in /usr/include/cygipc are irrelevant. Look into /usr/include/sys. If you want to change the values, reading /usr/share/doc/Cygwin/cygserver.README will help. I wasn't aware of /etc/cygserver.conf file, which was mentioned in the readme. Thanks. Regards Krzysztof Duleba -- 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: FYI: GNU Smalltalk 2.1.5 on Cygwin
Brian Ford [EMAIL PROTECTED] wrote on 19-05-2004 21:34:37: No, AFAIK, -lsomelib should never be in an automake _DEPENDENCIES target. That's a Makefile.am bug in GNU Smalltalk. Removing it from there should have been all that was required. You're absolutely right I tried again without the /lib/libgst.la line and it works like a charm. I'm no make expert and I was a bit afraid I took away to much if I deleted it there's also a -lreadline in the dependencies. I'll try and find out how the Makefile.am should be changed to avoid this in later builds, I'm 99% sure it's still there in 2.1.7 patrick -- 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: xemacs shell problem
Some old XEmacs (21.1 era) was handling this correctly, so I believe the problem is in XEmacs. I haven't had a chance to trace XEmacs code yet. I have been using the following work around. None of which is perfect. 1) Stick with an old XEmacs. 2) Do run /usr/local/bin/xemacs. You can search google for cygwin run. However, although it works the first a few times, the problem re-appears after a while. 3) Instead of compile with nmake -k (e.g.), do ssh localhost cd $PWD; nmake -k -- Rui-Tao Dong [EMAIL PROTECTED] sly5+gmane == Levent Yilmaz [EMAIL PROTECTED] writes: sly5+gmane Hi! After posting this message to emacs.xemacs.windows sly5+gmane and following the advices I have been told, I found out sly5+gmane that this happens only with Xemacs Cygwin build. Thus, I sly5+gmane hope it would be a relevant discussion for this group. sly5+gmane *the problem setting* The shell-mode(using bash) at sly5+gmane Xemacs(21.4.15) called from Bash (2.05b.0(1)-release) sly5+gmane running Cygwin(1.42) on WindowsXP-SP1 sly5+gmane *the ISSUE* Error messages from certain Windows console sly5+gmane programs (such as the Fortran compilers LaheyF95 and sly5+gmane Compaq Visual Fortran 6.6) (hereafter I will refer these sly5+gmane as Compiler) are not displayed at the sly5+gmane shell-buffer. Instead the errors are flushed to a DOS sly5+gmane console that dissappears immidiately after the sly5+gmane compilation is finished and the regular messages (logo sly5+gmane and stuff) are displayed at the shell-buffer as usual. sly5+gmane *complications* - When the Compiler is invoked directly sly5+gmane from Bash, everything works fine, all messages are there sly5+gmane and in fact, output redirection works as expected. The sly5+gmane error mesages can be redirected with the usual 2myfile. sly5+gmane - This issue does not occur with all console applications sly5+gmane (for instance I tried with MSVC++6/7 and they are working sly5+gmane fine). Among the ones I tested, only these fortran sly5+gmane Compilers has this behaviour. This is also why I fail to sly5+gmane find a reproducible example for submitting as a test case sly5+gmane here (though, you may download a trial version from sly5+gmane http://www.lahey.com/ and test with a erroneous Fortan sly5+gmane code, if you really agree that this is a significant sly5+gmane issue and worth the trouble). Here is a sample failing sly5+gmane FORTRAN code !== program fail end sly5+gmane program nail !== - As I mentioned sly5+gmane before this problem happens only with Xemacs Cygwin sly5+gmane build. Native-Windows build is working fine. sly5+gmane My question is, it seems that the output from the sly5+gmane Compiler is flushed to that blinking console, what may be sly5+gmane the cause of this? Are there other outputs other than sly5+gmane STDERR and STDOUT, that Cygwin is handling properly, but sly5+gmane the shell-mode in Xemacs is failing? sly5+gmane Thank you so very much!! - Levent -- Rui-Tao Dong (949) 673-1907 x116 (949) 673-1058(Fax) [EMAIL PROTECTED] ALL INFORMATION IN THIS EMAIL OR ATTACHED TO THIS EMAIL IS CONFIDENTIAL. -- 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 pty allocation code, race condition?
On Mon, 17 May 2004, Christopher Faylor wrote: On Mon, May 17, 2004 at 09:29:44AM -0400, John P. Rouillard wrote: Does the last cygwin snapshot contain any code changes in the pty allocation area? Yes, the very latest snapshot attempts to fix this problem. Please give it a try and report the results here. I'm sorry to report that the problem I described in http://cygwin.com/ml/cygwin/2004-05/msg00596.html (multiple xterms started in quick succession get the same PTY) still exists in the 20040519 snapshot. The output of ps after reproducing it with 4 xterms is below, if it's of any help (the last bash, PID 1948, is a console). $ ps PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 1732 11732 1748 con 1001 17:52:43 /usr/bin/xterm 2812 12812 1268 con 1001 17:52:43 /usr/bin/xterm 1160 11160 1152 con 1001 17:52:43 /usr/bin/xterm 1772 11772 1844 con 1001 17:52:43 /usr/bin/xterm S199617321996 20360 1001 17:52:53 /usr/bin/bash S124428121244 21200 1001 17:52:53 /usr/bin/bash I197211601972 21320 1001 17:52:53 /usr/bin/bash S198817721988 21280 1001 17:52:53 /usr/bin/bash 1948 11948 1948 con 1001 17:53:16 /usr/bin/bash 208819482088968 con 1001 17:53:19 /usr/bin/ps Note that now it's the third xterm that got a working bash, so I think my prior conclusion that the last one always wins was wrong. Note also that, for some reason, there was a 10-second delay between starting the xterms and having the bash shells started. As before, any ideas on how to debug this are appreciated. FWIW, cygcheck output is attached. 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! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton Cygwin Configuration Diagnostics Current System Time: Wed May 19 18:02:24 2004 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3 Path: C:\cygwin\home\igor\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\local\games C:\cygwin\usr\X11R6\bin c:\Program Files\IBM\Java14\bin c:\Program Files\IBM\Infoprint Select c:\ActivePerl\bin c:\MikTeX\miktex\bin c:\WINNT\system32 c:\WINNT c:\WINNT\system32\wbem c:\Program Files\IBM\Trace Facility c:\Program Files\Personal Communications c:\Notes c:\Utilities c:\Program Files\ThinkPad\Utilities c:\cygwin\bin .\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 1001(igor) GID: 544(Administrators) 544(Administrators) 10953([EMAIL PROTECTED]) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1001(igor) GID: 544(Administrators) 513(None)544(Administrators) 545(Users) SysDir: C:\WINNT\system32 WinDir: C:\WINNT CYGWIN = `check_case:strict ntsec notitle binmode nosmbntsec notty' HOME = `C:\cygwin\home\igor' MAKE_MODE = `unix' PWD = `/home/igor' USER = `igor' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\igor\Application Data' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `PECHTCHA' COMSPEC = `C:\WINNT\system32\cmd.exe' CVSREAD = `true' CVS_RSH = `/bin/ssh' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\igor' HOSTNAME = `pechtcha' JAVA_HOME = `/usr/contrib/java' JIKESPATH = `.:/usr/contrib/java/jre/lib/core.jar:/usr/contrib/java/jre/lib/charsets.jar' LOGONSERVER = `\\PECHTCHA' MANPATH = `/usr/local/man:/usr/man:/usr/autotool/devel/man:/usr/contrib/jikes/man::/usr/ssl/man:/usr/X11R6/man' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/tmp' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PCOMM_ROOT = `C:\Program Files\Personal Communications' PDBASE = `C:\Program Files\IBM\Infoprint Select' PDHOST = `ushawsrv01' PD_SOCKET = `6874' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0806' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' PS1 = `[\[\033[32m\]\h\[\033[0m\]:\[\033[33m\]\w\[\033[0m\]] \[\]' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TEMP = `C:\cygwin\tmp' TERM = `cygwin' TMP = `C:\cygwin\tmp' USERDOMAIN = `PECHTCHA' USERNAME = `igor' USERPROFILE = `C:\Documents and Settings\igor' WINDIR = `C:\WINNT' _ = `/usr
