inetutils source fix

[Sergiy Pavlov]

Module name:  inetutils v.3.2-25
Changes by: [EMAIL PROTECTED]   2004-02-18 13:14:58

Modified files:
.  : libnetutils/logwtmp.c

Log message:
source fix in libnetutils/logwtmp.c

Patch:
=
--- logwtmp.c 2000-07-05 07:44:42.0 -0400
+++ logwtmp.c 2004-02-18 13:14:58.0 -0500
@@ -110,7 +110,7 @@
 #else
 logwtmp (line, name, host)
 #endif
- char *line, *name, *host;
+ const char *line, *name, *host; /* match  */
 {
   struct utmp ut;

--
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: piping problems with cron+4nt

[Mironov, Leonid {PBG}]

Rafael Kitover wrote:
> Perhaps try using the cygstart utility, in conjunction with --hide?
> 
Yes, it helped. Thanks a lot.


>> -Original Message-
>> From: Mironov, Leonid {PBG}
>> Sent: Wednesday, February 18, 2004 12:59 AM
>> Subject: piping problems with cron+4nt
>> 
>> I've got a bunch of legacy 4NT batches I want to run from cygwin
>> cron. When run from 4NT started from bash these batches work fine
>> but when started from cron all lines with redirection and piping
>> fail, e.g. when I run 
>> 
>>   dir>q
>> 
>> file 'q' is not created,
>> 
>>   dir|sort
>> 
>> starts sort and it sits and waits for keyboard input. Also output
>> from external programs is lost, e.g. if batch looks like
>> 
>>   echo zzz
>>   zip zzz *
>>   echo qqq
>> 
>> and is run as
>> 
>> 02   *   *   *   4NT.EXE /c
>> ibackup.btm>>h:\\backup\\bk.log
>> 
>> file h:\backup\bk.log will look like
>> 
>>   zzz
>>   qqq
>> 
>> zip output is missing, although zip archive is created.
>> 
>> Any ideas?
>> 
>> Win XP SP1, just refreshed cygwin and 4NT to latest bulds whith no
>> effect at all. 
>> 
>> :), Leo



:), Leo

---
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


--
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: Repeatable crash with CVS version of cygwin1 DLL

[Christopher Faylor]

On Wed, Feb 18, 2004 at 11:03:21PM -0600, Cliff Geschke wrote:
>I have tried the latest update from CVS.  Still crashes, but stackptr
>does not go out-of-bounds.  At some point, _sigbe tries to ret with the
>top of stack ($esp) value set to 0.
>
>Some additional data points:
>
>1.  I moved the test .exe file to a Win2000 box running an old
>cygwin1.dll (file version 1005.5.0.0, product version 1.5.5-cr-0x9b).
>No crash.  The test seems to run fine.

Sorry.  The fact that this worked in 1.5.5 is uninteresting.

I did ask for it by commenting in another message that I would like to
know the regression points but that is more for someone who says, out of
the blue, "The snapshot is broken!" with no hint of when something
stopped working.

>2.  I moved the new 1.5.8 cygwin1.dll back to that Win2000 box.  Test
>crashes.

So, if you use the version that is known not to work, it crashes.  Um,
er...

>It is not feasible for me to put together a simple test program, unless
>you want load and build RTEMS so you can link to it.

Huh?  I don't understand.  Isn't RTEMS an OS?

Have you actually tried to build a test case using the stub from your
original message?

>If you trust me, I can push you the test .exe file.  I can uuencode it to
>probably get past your filters.  But that seems like a poor thing to post to
>this list.  Do you want me to email it or push it somewhere else?
>
>Please advise.

If the .exe is not too large then send it to the mailing list so that it
can be archived.

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: Repeatable crash with CVS version of cygwin1 DLL

[Cliff Geschke]

I have tried the latest update from CVS.  Still crashes, but stackptr does not
go out-of-bounds.  At some point, _sigbe tries to ret with the top of stack
($esp) value set to 0.

Some additional data points:

1. I moved the test .exe file to a Win2000 box running an old cygwin1.dll (file
version 1005.5.0.0, product version 1.5.5-cr-0x9b).  No crash.  The test seems
to run fine.

2. I moved the new 1.5.8 cygwin1.dll back to that Win2000 box.  Test crashes.

It is not feasible for me to put together a simple test program, unless you want
load and build RTEMS so you can link to it.

If you trust me, I can push you the test .exe file.  I can uuencode it to
probably get past your filters.  But that seems like a poor thing to post to
this list.  Do you want me to email it or push it somewhere else?

Please advise.

Cliff Geschke

-Original Message-
From: Christopher Faylor [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 18, 2004 4:43 PM
Subject: Re: Repeatable crash with CVS version of cygwin1 DLL

On Wed, Feb 18, 2004 at 10:31:03AM -0600, Cliff Geschke wrote:
>cygwin-1.5.7-1
>cygwin-SPLAT-cygwin-BOP-com

Please, avoid putting raw email addresses in messages.  They serve no purpose
and are spambot fodder.

>After doing what you asked, the crash still occurs, but is somewhat 
>different.  Here is what I did.
>
>1. Loaded cygwin from CVS.  I see the relevant routines have all changed.
>2. ./configure
>3. make
>4. build failed for dumper.exe (will send separate email) 5. Replaced  
>/usr/bin/cygwin1.dll with new-cygwin1.dll 6. Reboot (just to be safe) 
>7. Ran my test program.
>
>I am still seeing stackptr being corrupted.  I believe it happens after 
>a setjmp/longjump.  See "do_jump" routine below.
>
>I think the problem is in the "call _set_process_mask" in sigreturn.
>That somehow winds up calling _sigbe with the thread stack empty.
>
>Look for "" below for start of debug sections.
>
>I can supply the .exe test program if you wish.
>
>Good luck and thanks,

Thank you for providing an impressive amount of detail.  I have made some
changes to setjmp/longjmp.  I don't know if they fix your problems but I did
manage to write a very simple test case which illustrated a problem with using
setjmp/longjmp in signal handlers.





--
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: good top program for cygwin

[James Hu]

On 2004-02-18, Christopher Faylor wrote:
> On Wed, Feb 18, 2004 at 10:24:55AM -0500, Larry Hall wrote:
>>Then you either do not have the 'top' that's part of Cygwin or your
>>environment is incorrect.  Try installing/upgrading the procps package.
>>There's a man page for the Cygwin version of 'top' that comes with this
>>package.  I don't know if this will help you with the issue you
>>originally had or not but the documentation for Cygwin's 'top' is
>>definitely available.
>
> It won't help.  'top' uses /proc to get its info and /proc currently
> only has information on cygwin processes.
>
> cgf

Not incredibly useful, but it shows the windows processes.

  #!/bin/bash
  n=15
  if [ $# != 0 ] ; then n=$1 ; fi
  n=$[n+1]
  while : ; do clear ; ps -sW | head -$n ; sleep 1 ; done
  #END OF FILE

Type ^C to quit.

-- James


--
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: 20040217 snapshot problem

[Christopher Faylor]

On Wed, Feb 18, 2004 at 11:23:02AM -0500, Richard Campbell wrote:
>> Is this a regression from 20040216 or some other snapshot?
>
>Unless there are earlier post 1.5.7-1 snapshots than 20040205, no.
>
>I just ran through the 20040205-20040216 snapshots:
>
>20040216 - same result as 20040217
>20040215 - exception violation at x0005 or similar.  affects all cygwin programs, 
>not 
>   just XWin.exe
>20040214 - same result as 20040217
>20040213 - same result as 20040217
>20040206 - same result as 20040217
>20040205 - same result as 20040217

There are some changes in the latest snapshot that may make inetd
work better.  I tracked down a stupid error that I'd introduced after
1.5.7.

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/

Gdb runtime error

[Chih-Yi Kuan]

After the cygwin setup from the cygwin installer. Execution of gdb in
bash results in the follow error message:

*

 3 [main] ? 3552 cygheap_fixup_in_child: Couldn't reserve space
for cygwin's heap (0x6167 <0x15A>) in child, Win32 error 487
C:\cygwin\bin\gdb.exe (3552): *** m.AllocationBase 0x0, m.BaseAddress
0x6167, m.RegionSize 0xB8, m.State 0x1

**

Could anybody help me about this?
Following is the output from my cygcheck:



Found: C:\cygwin\bin\gdb.exe
C:/cygwin/bin/gdb.exe
  C:\WINDOWS\System32\COMDLG32.DLL
C:\WINDOWS\System32\SHLWAPI.dll
  C:\WINDOWS\System32\msvcrt.dll
C:\WINDOWS\System32\KERNEL32.dll
  C:\WINDOWS\System32\ntdll.dll
  C:\WINDOWS\System32\GDI32.dll
C:\WINDOWS\System32\USER32.dll
C:\WINDOWS\System32\ADVAPI32.dll
  C:\WINDOWS\System32\RPCRT4.dll
C:\WINDOWS\System32\COMCTL32.dll
C:\WINDOWS\System32\SHELL32.dll
  C:\cygwin\bin\cygwin1.dll
  C:\cygwin\bin\cygiconv-2.dll
  C:\cygwin\bin\tcl84.dll
  C:\cygwin\bin\tk84.dll
C:\WINDOWS\System32\IMM32.DLL

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Thu Feb 19 13:14:39 2004

Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 1

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\ATI Technologies\ATI Control Panel
"C
C:\cygwin\Program Files\Symantec\Norton Ghost 2003\"
c:\matlab\bin\win32
c:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT
c:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
c:\Program Files\Microsoft Visual Studio\Common\Tools
c:\Program Files\Microsoft Visual Studio\VC98\bin

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1004(lawrence) GID: 513(None)
3(None)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1004(lawrence) GID: 513(None)
root)513(None)
544(Administrators)  545(Users)

SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS

HOME = `C:\cygwin\home\lawrence'
MAKE_MODE = `unix'
PWD = `/home/lawrence'
USER = `lawrence'

Use `-r' to scan registry

c:  hd  NTFS   13139Mb  95% CP CS UN PA FC System
d:  hd  NTFS   24983Mb  54% CP CS UN PA FC Data
e:  cd  CDFS 631Mb 100%CS UN   Warcraft III
f:  fd  FAT  124Mb  38% CPUN   CANON_DC

C:\cygwin  / system
textmode
C:\cygwin/bin  /usr/bin  system
textmode
C:\cygwin/lib  /usr/lib  system
textmode
C:\cygwin\usr\X11R6\lib\X11\fonts  /usr/X11R6/lib/X11/fonts  system
binmode
  /cygdrive system
textmode,cygdrive

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\grep.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\mv.exe
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Found: C:\cygwin\bin\sh.exe
Found: C:\cygwin\bin\tar.exe

   61k 2003/08/09 C:\cygwin\bin\cygbz2-1.dll
   14k 2003/08/10 C:\cygwin\bin\cygcharset-1.dll
7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll
  842k 2003/09/30 C:\cygwin\bin\cygcrypto-0.9.7.dll
  598k 2003/11/03 C:\cygwin\bin\cygcurl-2.dll
   22k 2004/02/10 C:\cygwin\bin\cygcygipc-2.dll
  380k 2002/07/24 C:\cygwin\bin\cygdb-3.1.dll
  831k 2003/09/20 C:\cygwin\bin\cygdb-4.1.dll
  487k 2002/07/24 C:\cygwin\bin\cygdb_cxx-3.1.dll
 1080k 2003/09/20 C:\cygwin\bin\cygdb_cxx-4.1.dll
  155k 2004/01/07 C:\cygwin\bin\cygexpat-0.dll
   71k 2004/01/13 C:\cygwin\bin\cygexslt-0.dll
  654k 2003/11/04 C:\cygwin\bin\cygfltknox-0.dll
   65k 2003/11/04 C:\cygwin\bin\cygfltknox_forms-0.dll
   81k 2003/11/04 C:\cygwin\bin\cygfltknox_gl-0.dll
  108k 2003/11/04 C:\cygwin\bin\cygfltknox_images-0.dll
  131k 2003/10/28 C:\cygwin\bin\cygfontconfig-1.dll
   45k 2001/04/25 C:\cygwin\bin\cygform5.dll
   35k 2002/01/09 C:\cygwin\bin\cygform6.dll
   48k 2003/08/09 C:\cygwin\bin\cygform7.dll
  361k 2003/10/25 C:\cygwin\bin\cygfreetype-6.dll
   28k 2003/07/20 C:\cygwin\bin\cyggdbm-3.dll
   30k 2003/08/11 C:\cygwin\bin\cyggdbm-4.dll
   19k 2003/03/22 C:\cygwin\bin\cyggdbm.dll
   15k 2003/07/20 C:\cygwin\bin\cyggdbm_compat-3.dll
   15k 2003/08/11 C:\cygwin\bin\cyggdbm_compat-4.dll
   69k 2003/08/10 C:\cygwin\bin\cyggettextlib-0-12-1.dll
   12k 2003/08/10 C:\cygwin\bin\cyggettextpo-0.dll
  134k 2003/08/10 C:\cygwin\bin\cyggettextsrc-0-12-1.dll
  349k 2003/12/08 C:\cygwin\bin\cygGraphicsMagick++-0.dll
 2169k 2003/12/08 C:\cygwin\bin\cygGraphicsMagick-0.dll
  489k 2003/08/09 C:\cygwin\bin\cygguile-12.dll
  489k

Re: ipctest for cygserver

[Charles Wilson]

Yitzchak Scott-Thoennes wrote:
Is there any plan to move cygipc's ipctest.exe to using cygserver?

Not really -- it relies on some specific, non-standard functions in 
libcygipc.

Several years ago, Robert Collins wrote a quickie "ipctest" package for 
use with the then-nascent cygserver -- but as far as I know, it was 
never publicly released.  Perhaps he'd be willing to dig that up and 
post it somewhere?

--
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: Pserver on cygwin corrupts binary files

[Charles Wilson]

Corinna Vinschen wrote:
On Feb 17 18:16, Alejandro Lopez-Valencia wrote:

Because when using textmode, cygwin changes the semantics of I/O
functions in the underlying C runtime. It does (and forces) EOL
conversion on all files read and written to the filesystem as well as
*sockets* and *pipes* for all applications compiled with the runtime.


Nope.  Sockets reads and writes are always binary.
The only problem is cvs has special code to do EOL munging itself.  I've 
tried to eliminate that cruft (or #ifdef it out) for the cygwin build, 
but I never tried to "certify" the pserver for use.  As far as I'm 
concerned, using the cygwin cvs as a pserver *server* is unsupported, 
although there have been rumors that it works.  For some people.  Under 
some (as usual, unspecified) conditions.

Of course, using cygwin cvs as a pserver *client* is always supported.

My point: to track down this issue will probably require getting dirty 
(e.g. tracing thru the code).

--
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: search and replace tool

[Brian Dessent]

Rafael Kitover wrote:
> 
> Not really cygwin specific, you can do something like:
> 
> perl -pi -e 's/old text/new text/' `find /where -name '*.txt'`
> 
> note those are backticks surrounding the find.
> 
> Use -pi.bak to make backup files in case you screw up. You will of course need
> to know how to use regular expressions (see man perlretut). If you need to do
> multiline replaces, you should probably write a script, or use some other
> solution.

And if you're expecting a LOT of files and/or files with odd characters
(e.g. space, quote) in their filenames, try this variant:

find /where -name \*.txt -print0 | xargs -0 perl -pe 's/old/new/`

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: search and replace tool (Attn: gawk maintainer)

[Larry Hall]

At 04:46 PM 2/18/2004, Igor Pechtchanski you wrote:
>On Wed, 18 Feb 2004, Larry Hall wrote:
>
>> At 02:59 PM 2/18/2004, dAniel hAhler you wrote:
>> >Hello cygwin-list,
>> >
>> >I'm looking for a search and replace tool to replace a text portion in
>> >a bunch (3500+) of files.
>> >
>> >That should be an easy one.. :)
>>
>> This isn't really Cywgin-specific.  As a result, it's off-topic for this
>> list.  I will, however, point you in one direction that could help.  'sed'
>> or 'awk' are good possibilities here.  





>Larry, you missed 'perl'.  How could you? ;-)


Just trying to instigate a riot. ;-)


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

opengl-1.1.0-7 glut.h does not define wchar_t

[Philip Lamb]

Hello,

The changes to  in w32api-2.5 expose a problem with the 
glut.h in opengl-1.1.0-7 package, file . The problem is 
that whcar_t is now required to be defined by 
/usr/include/w32api/GL/glu.h, however glut.h does not do so.

I'm not sure where the _best_ place to put a definition is; for 
myself I have put it at line 153 of glut.h. Others may wish to do so 
too, and perhaps a patch to the opengl package is in order if other 
more knowledgeable folks concur.

153,156d152
< # ifndef _WCHAR_T_DEFINED
< typedef unsigned short wchar_t;
< #  define _WCHAR_T_DEFINED
< # endif
The only other workaround I can see is adding an #include  
before every #include  which is neither elegant nor in the 
spirit of GLUT's philosophy of hiding platform dependencies.
--
Philip Lamb
[EMAIL PROTECTED]

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

Re: gcj problem...

[Jason Fu]

I do remember there's the same usage of gcj with javac and I did not notice 
the changes as mentioned in the links you mention.

Anyway, thanks.

Jason

> On Mon, 16 Feb 2004, Jason Fu wrote:
>
>> Any idea about it...
>>
>> $ gcj HelloWorld.java
>> 
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libcygwin.a(libcmain.o)(.text+0
x7c):
>> undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit
>> status
>>
>> =
>> public class HelloWorld
>> {
>> public static void main(String[] args)
>> {
>> System.out.println("Hello World!");
>> }
>> }
>> =
>>
>> http://www.hkucs.org:8080/~tsfu/
>
> Here's an idea:
>
>> Problem reports:   http://cygwin.com/problems.html
>
> Please pay particular attention to the bit about attaching the cygcheck
> output.
>   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

http://www.hkucs.org:8080/~tsfu/


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

w32api-2.5 missing GLU_ERROR definition.

[Philip Lamb]

Hello,

I've just upgraded from w32api-2.4 to -2.5. It looks like  
file included in 2.5 is missing a definition of GLU_ERROR. In 
w32api-2.4, GLU_ERROR is defined on line 76, and a commented out 
version on line 177 (for completeness I suppose). In w32api-2.5, the 
first definition has been removed, and the second you can still see 
commented out on line 123 of glu.h.

Suggested fix: amend line 123 of  in w32api package to read:
#define GLU_ERROR 100103
This bug breaks all sorts of existing code.
--
Philip Lamb
[EMAIL PROTECTED]
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: search and replace tool

[Yitzchak Scott-Thoennes]

On Wed, Feb 18, 2004 at 12:13:38PM -0800, Rafael Kitover wrote:
> Not really cygwin specific, you can do something like:
> 
> perl -pi -e 's/old text/new text/' `find /where -name '*.txt'`
> 
> note those are backticks surrounding the find.
> 
> Use -pi.bak to make backup files in case you screw up. You will of course need
> to know how to use regular expressions (see man perlretut). If you need to do
> multiline replaces, you should probably write a script, or use some other
> solution.

Under cygwin, .bak is the default.  From perl's README.cygwin:
   Inplace editing C of files doesn't work without doing a backup
   of the file being edited C because of windowish restrictions,
   therefore Perl adds the suffix C<.bak> automatically if you use C
   without specifying a backup extension.

Other options are sed or awk.

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

Checking Cygwin version (FAQ Alert!) (Was Re: map mouse button 4 or 5 to button 2?)

[Igor Pechtchanski]

On Wed, 18 Feb 2004, Jeffrey J. Gray wrote:

> [snip]
> ... and I'm running  hm, not sure how to check my Cygwin version,
> it's probably ~4 months old  on WinXP.

Jeff,

Just like on any Unix system, "uname -srv" will return the kernel (in
Cygwin's case, cygwin1.dll) version.  On Cygwin, you can also use
"cygcheck -srv" to get detailed information about your system (essential
for diagnosing Cygwin problems, see ), or
"cygcheck -cd" to just get the versions of all installed packages (or omit
the "-d" flag to also check them for integrity).  If you post the output
of either "cygcheck -srv" or "cygcheck -cd", please *attach* it to your
message, rather than including it inline.
Igor
P.S. I was surprised that this isn't in the FAQ.  David, could you please
add this, under the heading "What version of Cygwin do I have?" or
something?  Oh, and BTW, there's a "What version is this, anyway?" entry
that has nothing to do with this question, and is pretty confusing.
-- 
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/

ipctest for cygserver

[Yitzchak Scott-Thoennes]

Is there any plan to move cygipc's ipctest.exe to using cygserver?

--
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: Repeatable crash with CVS version of cygwin1 DLL

[Christopher Faylor]

On Wed, Feb 18, 2004 at 10:31:03AM -0600, Cliff Geschke wrote:
>cygwin-1.5.7-1
>cygwin-SPLAT-cygwin-BOP-com

Please, avoid putting raw email addresses in messages.  They serve no
purpose and are spambot fodder.

>After doing what you asked, the crash still occurs, but is somewhat
>different.  Here is what I did.
>
>1. Loaded cygwin from CVS.  I see the relevant routines have all changed.
>2. ./configure
>3. make
>4. build failed for dumper.exe (will send separate email)
>5. Replaced  /usr/bin/cygwin1.dll with new-cygwin1.dll
>6. Reboot (just to be safe)
>7. Ran my test program.
>
>I am still seeing stackptr being corrupted.  I believe it happens
>after a setjmp/longjump.  See "do_jump" routine below.
>
>I think the problem is in the "call _set_process_mask" in sigreturn.
>That somehow winds up calling _sigbe with the thread stack empty.
>
>Look for "" below for start of debug sections.
>
>I can supply the .exe test program if you wish.
>
>Good luck and thanks,

Thank you for providing an impressive amount of detail.  I have made
some changes to setjmp/longjmp.  I don't know if they fix your problems
but I did manage to write a very simple test case which illustrated a
problem with using setjmp/longjmp in signal handlers.

>
> Here is the program that I think triggers the problem
>
>
>static void do_jump(
>  Context_Control_overlay *currentp,
>  Context_Control_overlay *nextp
>)
>{
>  int status;
>
>  if (setjmp(currentp->regs) == 0) {/* Save the current context */
> longjmp(nextp->regs, 0);   /* Switch to the new context */
> _Internal_error_Occurred(
> INTERNAL_ERROR_CORE,
> TRUE,
> status
>   );
>  }
>}

I'd love to have a simple test case but the above isn't a program.  It
looks like a snippet of a program.  I'm not sure how to set this up to
duplicate your problem.

If you have a complete listing of a program which illustrates the problem,
please post it here.

In the meantime, I'd appreciate it if you would try the latest version from
CVS or the latest snapshot when it is available.  I'm regenning a new version
now with some fork changes that make inetd work better.

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: limiting strace?, was: failure of unzip and recent cygwin1.dll

[Igor Pechtchanski]

On Wed, 18 Feb 2004, Ross Boulet wrote:

> > On Wed, 18 Feb 2004, Ross Boulet wrote:
> >
> > > > On Wed, 18 Feb 2004, Ross Boulet wrote:
> > > >
>
> [...snip...]
>
> > Ok, time for "Pipes 101".  A pipe is essentially a bounded (character)
> > buffer.  The producer application fills the buffer (by writing to the
> > pipe), and the consumer application empties it (by reading from the
> > pipe). If the buffer is full, the producer application blocks (inside
> > the write) until room is available.  If there's no data to read, the
> > consumer application blocks.  The amount of pipe data stored in memory
> > is determined only by the size of the buffer.  For unbuffered pipes,
> > the amount is 1 character.
> >
> > Once the data is read from the buffer, its further fate is up to the
> > consumer application.  Some applications (like grep) act as filters,
> > and require only enough memory for the current line.  Some (like sort)
> > will read the whole input and store it in memory before processing it
> > (or use temporary files internally, but these have nothing to do with
> > the pipe itself).  If you're interested in the behavior of any
> > particular application, I suggest you look at the sources of the
> > corresponding package (available for *all* Cygwin packages).
> >   Igor
> > P.S. FYI, less doesn't necessarily read all of the input, and has
> > options limiting the amount of allocated memory.
>
> Thanks for the enlightenment Igor,
>
> I looked at the options for less and see what you mean.  The -b and -B
> options can be used to limit how much memory less consumes.
>
> A couple more questions - you mentioned buffered and unbuffered pipes.  What
> determines whether the pipe is buffered or unbuffered?  Is cygwin managing
> its own pipes, or passing them off to Windoze to manage?
>
> Thanks,
> Ross

Ross,

First off, data can actually be buffered in more than one place.  For
example, the stdio library can do its own buffering before the data even
gets to the pipe.

Pipe buffering properties can certainly be specified in the API calls that
create pipes.  I'm not sure whether they can be changed once the pipe is
created (probably yes, but you should look at the API documentation to
make sure).

As far as I know, Cygwin doesn't have its own pipe implementation, and
uses the underlying Windows one (at least on NT-based systems, I'm not
sure about Win9x).  Cygwin does, however, wrap the underlying Windows API
by functions providing POSIX semantics, so it may well be that it does
some manipulation before passing the parameters or data off to Windows.
For technical questions like these, looking at the Cygwin sources is your
best bet.  If you aren't certain about what a particular Windows call
does, MSDN is the place to go.
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

--
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: limiting strace?, was: failure of unzip and recent cygwin1.dll

[Ross Boulet]

> On Wed, 18 Feb 2004, Ross Boulet wrote:
> 
> > > On Wed, 18 Feb 2004, Ross Boulet wrote:
> > >

[...snip...]

> 
> Ok, time for "Pipes 101".  A pipe is essentially a bounded (character)
> buffer.  The producer application fills the buffer (by writing to the
> pipe), and the consumer application empties it (by reading 
> from the pipe).
> If the buffer is full, the producer application blocks 
> (inside the write)
> until room is available.  If there's no data to read, the consumer
> application blocks.  The amount of pipe data stored in memory is
> determined only by the size of the buffer.  For unbuffered pipes, the
> amount is 1 character.
> 
> Once the data is read from the buffer, its further fate is up to the
> consumer application.  Some applications (like grep) act as 
> filters, and
> require only enough memory for the current line.  Some (like 
> sort) will
> read the whole input and store it in memory before processing 
> it (or use
> temporary files internally, but these have nothing to do with the pipe
> itself).  If you're interested in the behavior of any particular
> application, I suggest you look at the sources of the corresponding
> package (available for *all* Cygwin packages).
>   Igor
> P.S. FYI, less doesn't necessarily read all of the input, and 
> has options
> limiting the amount of allocated memory.

Thanks for the enlightenment Igor,

I looked at the options for less and see what you mean.  The -b and -B
options can be used to limit how much memory less consumes.

A couple more questions - you mentioned buffered and unbuffered pipes.  What
determines whether the pipe is buffered or unbuffered?  Is cygwin managing
its own pipes, or passing them off to Windoze to manage?

Thanks,
Ross



--
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: search and replace tool (Attn: gawk maintainer)

[Igor Pechtchanski]

On Wed, 18 Feb 2004, Larry Hall wrote:

> At 02:59 PM 2/18/2004, dAniel hAhler you wrote:
> >Hello cygwin-list,
> >
> >I'm looking for a search and replace tool to replace a text portion in
> >a bunch (3500+) of files.
> >
> >That should be an easy one.. :)
>
> This isn't really Cywgin-specific.  As a result, it's off-topic for this
> list.  I will, however, point you in one direction that could help.  'sed'
> or 'awk' are good possibilities here.  Of course, you'd want to wrap
> these in a script that created a new file and then replaced the original
> with the result.  This same process could be used on any platform that
> supports these tools however so talking much about the details isn't really
> appropriate.  There's plenty of information on the net about these utilities
> if you're interested in finding out more about how they work.
>
> HTH,
> --
> Larry Hall

Larry, you missed 'perl'.  How could you? ;-)

FWIW, both perl and sed have the ability to edit files in-place (although
this functionality is somewhat buggy in sed, see, for example,
).

To make this more Cygwin-related, there is no man page for "awk" in
Cygwin.  There is one for "gawk".  Since /usr/bin/awk.exe is a symlink to
/usr/bin/gawk.exe, would it be possible to create a symlink to
/usr/share/man/man1/gawk.1 as /usr/share/man/man1/awk.1?  Corinna?
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

--
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: limiting strace?, was: failure of unzip and recent cygwin1.dll

[Igor Pechtchanski]

On Wed, 18 Feb 2004, Ross Boulet wrote:

> > On Wed, 18 Feb 2004, Ross Boulet wrote:
> >
> [...snip...]
> > > Just adding my 2 cents and hopefully to learn something:
> > >
> > > I know how to use pipes but I don't know how they are handled "under
> > > the covers".  Wouldn't piping the strace to tail or grep still
> > > produce a temporary file of a large size?  I don't know if the
> > > original poster is concerned with disk space or only the output.
> > > If it's a space issue and a temporary file is created for the pipe,
> > > I can see why he would want to limit the strace output directly.
> > > If its just the result, it seems tail or grep would be good options.
> > >
> > > Ross
> >
> > Pipes are direct process-to-process communication devices in most
> > (all?) modern operating systems.  Older systems (read: MS-DOS)
> > didn't have true pipes, and had to emulate them with redirection to
> > temporary files. AFAIK, Cygwin doesn't use temporary files for pipes
> > on any of the systems that it runs on.
> >   Igor
>
> Just for my own edification and at the risk of being slightly OT
>
> When you run:
>
> $ foo | bar
>
> I'm assuming the output from foo is stored in memory and then passed to
> bar as the output is generated.  I deduce this from experience when I run
>
> $ foo | less
>
> Less starts processing the output as it comes in.  Less would obviously
> require memory to store the entire output to facilitate paging back.
> However, grep would be looking at each line and only keeping what its been
> told.  So in
>
> $ foo | grep sometext
>
> Is the memory consumed by output from foo freed as soon as grep reads it and
> sees that sometext is not in the output line?

Ok, time for "Pipes 101".  A pipe is essentially a bounded (character)
buffer.  The producer application fills the buffer (by writing to the
pipe), and the consumer application empties it (by reading from the pipe).
If the buffer is full, the producer application blocks (inside the write)
until room is available.  If there's no data to read, the consumer
application blocks.  The amount of pipe data stored in memory is
determined only by the size of the buffer.  For unbuffered pipes, the
amount is 1 character.

Once the data is read from the buffer, its further fate is up to the
consumer application.  Some applications (like grep) act as filters, and
require only enough memory for the current line.  Some (like sort) will
read the whole input and store it in memory before processing it (or use
temporary files internally, but these have nothing to do with the pipe
itself).  If you're interested in the behavior of any particular
application, I suggest you look at the sources of the corresponding
package (available for *all* Cygwin packages).
Igor
P.S. FYI, less doesn't necessarily read all of the input, and has options
limiting the amount of allocated memory.
-- 
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: limiting strace?, was: failure of unzip and recent cygwin1.dll

[Ross Boulet]

> On Wed, 18 Feb 2004, Ross Boulet wrote:
> 
[...snip...]
> > Just adding my 2 cents and hopefully to learn something:
> >
> > I know how to use pipes but I don't know how they are 
> handled "under the
> > covers".  Wouldn't piping the strace to tail or grep still produce a
> > temporary file of a large size?  I don't know if the 
> original poster is
> > concerned with disk space or only the output.  If it's a 
> space issue and a
> > temporary file is created for the pipe, I can see why he 
> would want to limit
> > the strace output directly.  If its just the result, it 
> seems tail or grep
> > would be good options.
> >
> > Ross
> 
> Pipes are direct process-to-process communication devices in 
> most (all?)
> modern operating systems.  Older systems (read: MS-DOS) 
> didn't have true
> pipes, and had to emulate them with redirection to temporary files.
> AFAIK, Cygwin doesn't use temporary files for pipes on any of 
> the systems
> that it runs on.
>   Igor
Just for my own edification and at the risk of being slightly OT

When you run:

$ foo | bar

I'm assuming the output from foo is stored in memory and then passed to bar
as the output is generated.  I deduce this from experience when I run

$ foo | less

Less starts processing the output as it comes in.  Less would obviously
require memory to store the entire output to facilitate paging back.
However, grep would be looking at each line and only keeping what its been
told.  So in

$ foo | grep sometext

Is the memory consumed by output from foo freed as soon as grep reads it and
sees that sometext is not in the output line?

Thanks,
Ross



--
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: piping problems with cron+4nt

[Rafael Kitover]

Perhaps try using the cygstart utility, in conjunction with --hide?

>-Original Message-
>From: Mironov, Leonid {PBG}
>Sent: Wednesday, February 18, 2004 12:59 AM
>Subject: piping problems with cron+4nt
>
>I've got a bunch of legacy 4NT batches I want to run from cygwin cron. When
>run from 4NT started from bash these batches work fine but when started from
>cron all lines with redirection and piping fail, e.g. when I run
>
>   dir>q
>
>file 'q' is not created,
>
>   dir|sort
>
>starts sort and it sits and waits for keyboard input. Also output from
>external programs is lost, e.g. if batch looks like
>
>   echo zzz
>   zip zzz *
>   echo qqq
>
>and is run as
>
>0  2   *   *   *   4NT.EXE /c
>ibackup.btm>>h:\\backup\\bk.log
>
>file h:\backup\bk.log will look like
>
>   zzz
>   qqq
>
>zip output is missing, although zip archive is created.
>
>Any ideas?
>
>Win XP SP1, just refreshed cygwin and 4NT to latest bulds whith no effect at
>all.
>
>:), Leo


--
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 extending perl-5.8.2-1 via CPAN: Storable.dll

[Rafael Kitover]

This is an issue related to rebasing DLLs.

There's a "rebaseall" utility in Cygwin to fix this, unfortunately it does not
pick up non-package DLLs, including Perl extensions installed from CPAN shell.
I've made some changes to that script so that it does...which reminds me I need
to send out a patch, or something. Anyway, my "rebaseall" script is attached.
To run it, close any all Cygwin processes, open a bash shell, and run it.

HTH

-- 
Rafael

>-Original Message-
>From: Tino Lange
>Sent: Tuesday, February 17, 2004 10:09 AM
>To: The Cygwin Mailing List
>Subject: problem extending perl-5.8.2-1 via CPAN: Storable.dll
>
>Gerrit P. Haase wrote:
>> perl-5.8.2-1 release has been uploaded to sourceware
>>-- it should be on the mirrors soon.
>
>Hi Gerrit, hi List!
>
>I have a problem updating modules within the CPAN Shell. Perl itself
>crashes due to problems with Storable.dll?
>
>> cpan> install Mail::SpamAssassin
>> Running install for module Mail::SpamAssassin
>> Running make for F/FE/FELICITY/Mail-SpamAssassin-2.63.tar.gz
>> CPAN: Digest::MD5 loaded ok
>> CPAN: Compress::Zlib loaded ok
>> Checksum for /home/Tino/.cpan/sources/authors/id/F/FE/FELICITY/Mail-
>SpamAssassin-2.63.tar.gz ok
>> Scanning cache /home/Tino/.cpan/build for sizes
>> C:\cygwin\bin\perl.exe (3080): *** unable to remap
>C:\cygwin\lib\perl5\5.8.2\cygwin-thread-multi-64int\auto\Storable\Storable.dll
>to same address as parent(0xCE) != 0x120
>>   4 [main] perl 3168 sync_with_child: child 3080(0x6B0) died before
>initialization with status code 0x1
>>6993 [main] perl 3168 sync_with_child: *** child state child loading dlls
>
>Can you give me a hint?
>I have searched the mailing list and the web for appropiate keywords,
>but I couldn't find a solution there.
>
>Attaches is a cygcheck.out. Please let me know if you need more information.
>
>Please always CC to me, since I'm not on the list.
>
>Thanks for your help!
>
>Tino


rebaseall
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: stabilizing cygwin emacs

[Richard Campbell]

>> And if I could start X under 20040217, emacs might well not crash.
>
>So your problems have appeared while running -nw?

No, no.  My problem of intermittent crashes has occurred running emacs 
under X under cygwin 1.5.7-1.

Under cygwin 20040217 (or any post 1.5.7-1 snapshot), I cannot start X 
at all.  As a result, I have reverted to 1.5.7-1.

What I was saying was that since 20040217 fixed emacs problems for others,
it might work for me as well.  However, I can't tell because I'm unwilling
to give up X.

-Richard Campbell.

--
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: search and replace tool

[Larry Hall]

At 02:59 PM 2/18/2004, dAniel hAhler you wrote:
>Hello cygwin-list,
>
>I'm looking for a search and replace tool to replace a text portion in
>a bunch (3500+) of files.
>
>That should be an easy one.. :)
>
>


This isn't really Cywgin-specific.  As a result, it's off-topic for this 
list.  I will, however, point you in one direction that could help.  'sed' 
or 'awk' are good possibilities here.  Of course, you'd want to wrap
these in a script that created a new file and then replaced the original 
with the result.  This same process could be used on any platform that
supports these tools however so talking much about the details isn't really
appropriate.  There's plenty of information on the net about these utilities
if you're interested in finding out more about how they work.

HTH,


--
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: stabilizing cygwin emacs

[Thomas L Roche]

Richard Campbell Wed, 18 Feb 2004 13:44:10 -0500
> Intermittent crashes, sometimes with a stackdump produced, sometimes
> not. Generally after several hours/days of execution.

Tom Roche wrote:
>> Hmm ... I don't recall ever having that problem on either 1.5.7-1
>> (my problems have involved emacs crashing after starting, not
>> failing to start) or 20040217 (on which emacs hasn't crashed yet).

> And if I could start X under 20040217, emacs might well not crash.

So your problems have appeared while running -nw?

FWIW, IIRC all the other reports about problems with emacs with cygwin
> 1.5.5-1 have involved emacs under X, so that alone (if I understand
you correctly) is an interesting datapoint.


--
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: search and replace tool

[Rafael Kitover]

Not really cygwin specific, you can do something like:

perl -pi -e 's/old text/new text/' `find /where -name '*.txt'`

note those are backticks surrounding the find.

Use -pi.bak to make backup files in case you screw up. You will of course need
to know how to use regular expressions (see man perlretut). If you need to do
multiline replaces, you should probably write a script, or use some other
solution.

-- 
Rafael

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>dAniel hAhler
>Sent: Wednesday, February 18, 2004 12:00 PM
>To: cygwin-list
>Subject: search and replace tool
>
>Hello cygwin-list,
>
>I'm looking for a search and replace tool to replace a text portion in
>a bunch (3500+) of files.
>
>That should be an easy one.. :)

--
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: limiting strace?, was: failure of unzip and recent cygwin1.dll

[Igor Pechtchanski]

On Wed, 18 Feb 2004, Ross Boulet wrote:

> > On Mon, 16 Feb 2004, Thomas L Roche wrote:
> >
> > > Is there a way to limit the size of the strace output _file_, rather
> > > than just the output file buffer, while preserving desired
> > > information?
> > >
> > > I previously used strace to debug the problem that 20040213 induced
> > > in emacs 'desktop', therefore in emacs' startup; nevertheless the
> > > resulting strace.out was > 21 MB. Thus I am somewhat hesitant to
> > > avail myself of
> > >
> > > Christopher Faylor Sun, 15 Feb 2004 21:12:02 -0500
> > > > more strace output for the failing condition, meaning that if you do
> > > > this:
> > >
> > > >   strace -o strace.out unzip whatever
> > >
> > > > it should produce a large strace file.
> > >
> > > (quite the understatement :-) since
> > >
> > > * the unzip SEGVs typically occur after 30-60 min runtime
> > >
> > > * I have < 5 GB free space.
> > >
> > > Is there a way to limit the file size directly, or to script its
> > > rotation?
> > >
> > > Alternatively, is there a recommended mask setting that will preserve
> > > the desired information, while not blowing out my disk? I'm assuming
> > > 'malloc' would be part of the recommended setting: anything else?
> >
> > You're on Cygwin, man!  Use the scripting tools! :-)
> >
> > Don't forget that strace by default sends the trace to stdout.  You
> > can then pipe it to any program you wish (e.g., "tail -100", or "grep
> > -v ...", or a whole bunch of others).  You can then redirect the
> > output of the pipe chain to a file, if you wish...
> >   Igor
>
> Just adding my 2 cents and hopefully to learn something:
>
> I know how to use pipes but I don't know how they are handled "under the
> covers".  Wouldn't piping the strace to tail or grep still produce a
> temporary file of a large size?  I don't know if the original poster is
> concerned with disk space or only the output.  If it's a space issue and a
> temporary file is created for the pipe, I can see why he would want to limit
> the strace output directly.  If its just the result, it seems tail or grep
> would be good options.
>
> Ross

Pipes are direct process-to-process communication devices in most (all?)
modern operating systems.  Older systems (read: MS-DOS) didn't have true
pipes, and had to emulate them with redirection to temporary files.
AFAIK, Cygwin doesn't use temporary files for pipes on any of the systems
that it runs on.
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

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

search and replace tool

[dAniel hAhler]

Hello cygwin-list,

I'm looking for a search and replace tool to replace a text portion in
a bunch (3500+) of files.

That should be an easy one.. :)


-- 
shinE!
http://www.thequod.de ICQ#152282665
GnuPG/PGP key: http://thequod.de/danielhahler.asc


--
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: Strange group name

[DePriest, Jason R.]

> -Original Message-
> From: cygwin-owner at cygwin dot com 
> [mailto: cygwin-owner at cygwin dot com] On Behalf Of Igor
Pechtchanski
> Sent: Wednesday, February 18, 2004 8:46 AM
> To: Julian C H Stevens
> Cc: cygwin at cygwin dot com
> Subject: Re: Strange group name
> 
> 
> On Wed, 18 Feb 2004, Julian C H Stevens wrote:
> 
> > I have installed cygwin 1.5.6(0.108/3/2) and I notice that 
> the files in
> > my home directory have a group ownership of "mkgroup-l-d".
> >
> > I'm new to cygwin, and have installed it as a domain user on a
> > workstation running Windows 2000 Professional Ver 5.0 Build 
> 2195 Service
> > Pack 4.
> >
> > Please could someone suggest how this strange group name 
> has got into my
> > /etc/group file?
> 
> > Thanks,
> > Julian.
> 
> Julian,
> 
> 
explains
> this somewhat, but should be updated to say that "mkgroup-l-d" means
that
> the files are owned by a domain group that isn't in your /etc/group,
and
> that you should run "mkgroup -l -d >> /etc/group" when you're
connected to
> a domain controller to fix this.  Otherwise, that group name is
harmless,
> IIRC.  Perhaps Pierre or Corinna could chime in here...
>   Igor
> P.S. Could you please set your mailer to wrap long lines?
> -- 
>   http://cs.nyu.edu/~pechtcha/
>   |\  _,,,---,,_  pechtcha at cs dot nyu dot edu
> ZZZzz /,`.-'`'-.  ;-;;,_  igor at watson dot ibm dot com
>  |,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
> 
> --

If you are a member of a domain with a huge number of groups, you can
take a short cut to figure out what mkgroup-l-d is really looking for.

I did this:

[EMAIL PROTECTED] ~
$ ls -n -l
total 40
-rw---1 43363105138591 Feb 17 12:47 .bash_history
-rwxr-xr-x1 4336310513 533 Dec 10 17:48 .bash_profile*
-rwxr-xr-x1 4336310513 625 Dec 10 17:48 .bashrc*
drwxr-xr-x+   4 43363105134096 Jan  8 18:02 .cpan/
-rwxr-xr-x1 4336310513 267 Dec 10 17:48 .inputrc*
drwx--+   2 4336310513   0 Dec 23 11:34 .links/
drwxr-xr-x+   2 4336310513   0 Dec 15 13:07 .ncftp/
drwx--+   2 43363105134096 Jan  8 14:20 .ssh/
-rw---1 43363105136020 Feb  9 15:04 .viminfo
-rwxr-xr-x1 4336310513 205 Dec 15 13:17 .wgetrc*
[EMAIL PROTECTED] ~
$ mkgroup -d | grep 10513
Domain Users:S-1-5-21-1718497100-374411357-7473742-513:10513:
[EMAIL PROTECTED] ~
$ 

The '-n' lists the user names and groups as their GID/UID number.  I
then used mkgroup to list all the domain groups and grep'd for the GID
listed.
Problem solved.  It was looking for Domain Users.
I can just put that entry in my /etc/group file and all is good now.

See:

[EMAIL PROTECTED] ~
$ ls -l
total 40
-rw---1 depriest users_d  8591 Feb 17 12:47 .bash_history
-rwxr-xr-x1 depriest users_d   533 Dec 10 17:48 .bash_profile*
-rwxr-xr-x1 depriest users_d   625 Dec 10 17:48 .bashrc*
drwxr-xr-x+   4 depriest users_d  4096 Jan  8 18:02 .cpan/
-rwxr-xr-x1 depriest users_d   267 Dec 10 17:48 .inputrc*
drwx--+   2 depriest users_d 0 Dec 23 11:34 .links/
drwxr-xr-x+   2 depriest users_d 0 Dec 15 13:07 .ncftp/
drwx--+   2 depriest users_d  4096 Jan  8 14:20 .ssh/
-rw---1 depriest users_d  6020 Feb  9 15:04 .viminfo
-rwxr-xr-x1 depriest users_d   205 Dec 15 13:17 .wgetrc*
[EMAIL PROTECTED] ~
$ 

I changed the display name of the group from 'Domain Users' to 'users_d'
in my /etc/group file so it would fit in the column better.

-Jason


--
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: limiting strace?, was: failure of unzip and recent cygwin1.dll

[Ross Boulet]

> 
> On Mon, 16 Feb 2004, Thomas L Roche wrote:
> 
> > Is there a way to limit the size of the strace output _file_, rather
> > than just the output file buffer, while preserving desired
> > information?
> >
> > I previously used strace to debug the problem that 20040213 
> induced in
> > emacs 'desktop', therefore in emacs' startup; nevertheless the
> > resulting strace.out was > 21 MB. Thus I am somewhat 
> hesitant to avail
> > myself of
> >
> > Christopher Faylor Sun, 15 Feb 2004 21:12:02 -0500
> > > more strace output for the failing condition, meaning 
> that if you do
> > > this:
> >
> > >   strace -o strace.out unzip whatever
> >
> > > it should produce a large strace file.
> >
> > (quite the understatement :-) since
> >
> > * the unzip SEGVs typically occur after 30-60 min runtime
> >
> > * I have < 5 GB free space.
> >
> > Is there a way to limit the file size directly, or to script its
> > rotation?
> >
> > Alternatively, is there a recommended mask setting that 
> will preserve
> > the desired information, while not blowing out my disk? I'm assuming
> > 'malloc' would be part of the recommended setting: anything else?
> 
> You're on Cygwin, man!  Use the scripting tools! :-)
> 
> Don't forget that strace by default sends the trace to 
> stdout.  You can
> then pipe it to any program you wish (e.g., "tail -100", or 
> "grep -v ...",
> or a whole bunch of others).  You can then redirect the 
> output of the pipe
> chain to a file, if you wish...
>   Igor
> -- 

Just adding my 2 cents and hopefully to learn something:

I know how to use pipes but I don't know how they are handled "under the
covers".  Wouldn't piping the strace to tail or grep still produce a
temporary file of a large size?  I don't know if the original poster is
concerned with disk space or only the output.  If it's a space issue and a
temporary file is created for the pipe, I can see why he would want to limit
the strace output directly.  If its just the result, it seems tail or grep
would be good options.

Ross



--
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: good top program for Cygwin

[Simon]

Thanks Larry - that was it - added procps and now works alot better...
cheers Simon
[/cygdrive/h] Bash ver:2.05b.0 Wed Feb 18
 $ man top
TOP(1)Linux User's Manual
TOP(1)

NAME
   top - display top CPU processes

SYNOPSIS
   top [-] [d delay] [p pid] [q] [c] [C] [S] [s] [i] [n iter] [b]

DESCRIPTION
   top  provides  an  ongoing look at processor activity in real time.
It
   displays a listing of the most CPU-intensive tasks on the  system,
and
   can  provide  an  interactive interface for manipulating processes.
It
   can sort the tasks by CPU usage, memory usage and runtime.  can be
bet-
   ter  configured than the standard top from the procps suite.  Most
fea-
   tures can either be selected by an interactive command or by
specifying
   the  feature  in  the  personal  or system-wide configuration file.
See
   below for more information.

- Original Message - 
From: "Larry Hall" <[EMAIL PROTECTED]>
To: "Simon" <[EMAIL PROTECTED]>; "Cygwin List" <[EMAIL PROTECTED]>
Sent: Wednesday, February 18, 2004 3:24 PM
Subject: Re: good top program for Cygwin


> Then you either do not have the 'top' that's part of Cygwin or your
> environment is incorrect.  Try installing/upgrading the procps package.
> There's a man page for the Cygwin version of 'top' that comes with this
> package.  I don't know if this will help you with the issue you originally
> had or not but the documentation for Cygwin's 'top' is definitely
available.
>
> Larry
>
>
> At 09:07 AM 2/18/2004, Simon you wrote:
> >Of course :
> > $ man top
> >No manual entry for top
> >
> >Simon
> >
> >- Original Message - 
> >From: "Larry Hall" <[EMAIL PROTECTED]>
> >To: "Simon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> >Sent: Tuesday, February 17, 2004 6:42 PM
> >Subject: Re: good top program for Cygwin
> >
> >
> >> At 10:32 AM 2/17/2004, Simon you wrote:
> >>
> >> >Anyone know of a decent top program to run from the command line?
> >> >The one i have with cygwin installation has no help
> >>
> >>
> >> Did you try 'man top'?
> >>
> >>
> >> --
> >> 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/
>
>

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

[Krzysztof Duleba]

Brian Dessent wrote:
>
>> A translator that changes int 0x80 to function calls? It doesn't seem too
>> difficult, but I probably miss something.
>
> So write a perl script.
>  The list of syscalls is defined in the Linux
> kernel in unistd.h:
>

>
> You may also want to read these pages:
> 

Thanks. I'll check it up as soon as I have some spare time.

> > The way I think is: if in Linux it is possible to translate function
calls
> > to int 0x80, one could build a funcion call -> int 0x80 dictionary. If
the
> > dictionary is complete (or at least big enough), having a int 0x80-like
> > system call one can look up the corresponding funcion call.
>
> I don't know what you're trying to do here but it sounds like it's not
> going to work.  If you're trying to compile code written in assember
> then you should have the source with symbolic calls and not raw
> syscalls,
> otherwise the person writing the code was an idiot.

Agree, at least to some extend.

>  If you're
> trying to decompile and port some random linux binary to run under
> Cygwin, then I must conclude that you're nuts.

No. But the idea sound great anyway :-)

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: stabilizing cygwin emacs, was: 20040217 snapshot problem

[Richard Campbell]

>> I was trying the 20040217 snapshot to see if it cleared up the emacs
>> problems I was having (which haven't been repeatable enough for me
>> to report). 
>
>Umm ... what problems?

Intermittent crashes, sometimes with a stackdump produced, sometimes not.
Generally after several hours/days of execution.  As I said, not repeatable 
enough to be useful.  

>Hmm ... I don't recall ever having that problem on either 1.5.7-1 (my
>problems have involved emacs crashing after starting, not failing to
>start) or 20040217 (on which emacs hasn't crashed yet). 

And if I could start X under 20040217, emacs might well not crash.

>You wanna try debugging emacs? 

I'd have to try debugging X first.  Guess I'll dust off the instructions 
for building a debug X server.

-Richard Campbell.

--
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: Java Thread Dump in Bash

[Randall R Schulz]

Frank-Michael,

I hesitate to continue this on the Cygwin list, but I will, for now.

At 09:45 2004-02-18, Frank-Michael Moser wrote:
Randall, does your Java application die after pressing Ctrl-Break or not?
It appears it terminates. As you've had me trying this much more than I 
ever have in the past, I've found that the behavior is not really very 
uniform or predictable.

When the program's standard input and output are not redirected, I see 
the thread dump and the program dies--usually, but not quite always. 
Sometimes the program just terminates. I had interpeted the termination 
as an indication of an end-of-file having been generated, but that may 
have been incorrect.

When I run the program with standard input, output and error redirected 
to files and type CTRL-BREAK, the program terminates but the thread 
dump is nowhere to be seen in the file that received standard output, 
the file that received standard error nor the console / tty.

I could hypothesize that the recent changes in Cygwin signal handling 
might have something to do with this. However, I know nothing of the 
details of this change, just that a change was mentioned in the Cygwin 
release notes. So this is really just blind speculation, especially 
since I really don't have much of a basis for comparison (in a 
before-and-after sense).

Randall Schulz 

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

[Brian Dessent]

Krzysztof Duleba wrote:

> A translator that changes int 0x80 to function calls? It doesn't seem too
> difficult, but I probably miss something.

So write a perl script.  The list of syscalls is defined in the Linux
kernel in unistd.h:


You may also want to read these pages:


> The way I think is: if in Linux it is possible to translate function calls
> to int 0x80, one could build a funcion call -> int 0x80 dictionary. If the
> dictionary is complete (or at least big enough), having a int 0x80-like
> system call one can look up the corresponding funcion call.

I don't know what you're trying to do here but it sounds like it's not
going to work.  If you're trying to compile code written in assember
then you should have the source with symbolic calls and not raw
syscalls, otherwise the person writing the code was an idiot.  If you're
trying to decompile and port some random linux binary to run under
Cygwin, then I must conclude that you're nuts.

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: Re: Entry point _fcntl64 not found, Cygwin version 1.5.5

[Pavan Mandalkar]

Hi Brain,

>Have you tried looking at this message and some og the others related in 
>this 
>area:

>http://www.cygwin.com/ml/cygwin/2004-01/msg01377.html

>What version of ash are you running versus the 1.5.5 version of Cygwin?

Thanks for this pointer. The problem was solved after I switched to ash 
20031007 version from the 2004 version.

Thanks again.

Pavan U M


--
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: Java Thread Dump in Bash

[Frank-Michael Moser]

Randall, does your Java application die after pressing Ctrl-Break or not?

Frank-Michael

Randall R Schulz wrote:

Frank-Michael,

At 12:09 2004-02-17, Frank-Michael Moser wrote:

Unfortunately neither Ctrl-Break nor Ctrl-Scroll produce a thread dump 
not in pure bash and not in RXVT for me. I'm using latest cygwin and 
tried JDK 1.4.2_02 and 1.5.0 beta.

Also the java applications I tried do not read from standard input.

What versions (cygwin/java) do you use.


Cygwin: Latest "kernel" and latest version of all packages.
Java: Latest (specifically, 1.4.2_03); If it might matter, I generally 
use the "java" and "javac" commands from the SDK bin, not the "jre" bin. 
That's the directory that includes the compiler and related development 
tools, where as the jre bin has only the JVM and other runtime resources.

By "pure BASH" I take it you mean BASH in a console window, in contrast 
to an RXVT window. I do _not_ use the "tty" option in the CYGWIN 
environment variable. Do you?


Is it worth to send my cygcheck output attached? Should I really 
expect Ctrl-Break to work - this would be great?


I expect it to work because it does work for me...

Cygcheck output isn't anything I can use for any purpose I can think of 
in resolving this discrepancy between how your system and mine behave.


Frank-Michael


Randall Schulz


Randall R Schulz wrote:

Frank-Michael,

CTRL-BREAK produces a thread-dump using the latest Sun JVM on my 
system when launched from BASH. However, if the program is reading 
standard input from the unredirected console, it receives an 
end-of-file indication on that stream as well.

Randall Schulz

At 03:42 2004-02-17, Frank-Michael Moser wrote:

Searching the mailing list archive I found that there is an old 
thread from Dec 2000 which exactly describes my problem:

http://sources.redhat.com/ml/cygwin/2000-12/msg00490.html

In short: Using Ctrl-Scroll does not cause a Java program to dump 
threads as it does in cmd.exe. Unfortunately the thread ended up 
with some personal strife.

I understand that the signal problem could be by design. But now (3 
years later) maybe there are news about this issue? Has someone a 
way to work around this problem?

Frank-Michael


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


--

DECODON GmbHphone: +49(0)3834 515231
W.-Rathenau-Str. 49a  fax: +49(0)3834 515239
17489 Greifswaldemail: [EMAIL PROTECTED]
Germany   web:   www.decodon.com

--
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.7-1: dumper.exe build fails with source from CVS

[Cliff Geschke]

cygwin-1.5.7-1
[EMAIL PROTECTED]

When I attempt to build the complete cygwin from source, it fails
while building dumper.exe

1. Load sources from CVS
2. ./configure
3. make
4. Lots of stuff gets built
5. Fails during dumper.exe build

End of trace appended below.

I am guessing it wants a new libintl.a that is not installed, rather
than the one it finds in /usr/lib.

I can send any config.* files you might want.

Good luck

Cliff Geschke



...

c++ -L/home/Cliff/cygwin/src/i686-pc-cygwin/winsup -L/home/Cliff/cygwin/src/i686
pc-cygwin/winsup/cygwin -L/home/Cliff/cygwin/src/i686-pc-cygwin/winsup/w32api/li
 -isystem /home/Cliff/cygwin/src/winsup/include -isystem /home/Cliff/cygwin/src/
insup/cygwin/include -isystem /home/Cliff/cygwin/src/winsup/w32api/include -B/ho
e/Cliff/cygwin/src/i686-pc-cygwin/newlib/ -isystem /home/Cliff/cygwin/src/i686-p
-cygwin/newlib/targ-include -isystem /home/Cliff/cygwin/src/newlib/libc/include
c -nostdinc++ -g -O2 -fno-exceptions -fno-rtti -DHAVE_DECL_GETOPT=0 -Wall -Wwrit
-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -I. -I/home/Cliff/cygwin
src/winsup/cygwin -I/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include -fno-rtti -fno
exceptions -c -o dumper.o -I/home/Cliff/cygwin/src/bfd -I/home/Cliff/cygwin/src/
nclude ../../.././winsup/utils/dumper.cc
c++ -L/home/Cliff/cygwin/src/i686-pc-cygwin/winsup -L/home/Cliff/cygwin/src/i686
pc-cygwin/winsup/cygwin -L/home/Cliff/cygwin/src/i686-pc-cygwin/winsup/w32api/li
 -isystem /home/Cliff/cygwin/src/winsup/include -isystem /home/Cliff/cygwin/src/
insup/cygwin/include -isystem /home/Cliff/cygwin/src/winsup/w32api/include -B/ho
e/Cliff/cygwin/src/i686-pc-cygwin/newlib/ -isystem /home/Cliff/cygwin/src/i686-p
-cygwin/newlib/targ-include -isystem /home/Cliff/cygwin/src/newlib/libc/include
o dumper.exe module_info.o parse_pe.o dumper.o -B/home/Cliff/cygwin/src/i686-pc-
ygwin/winsup/cygwin/ -B/home/Cliff/cygwin/src/i686-pc-cygwin/newlib/libc -B/home
Cliff/cygwin/src/i686-pc-cygwin/winsup/w32api/lib  -lnetapi32 -ladvapi32 /usr/li
/gcc-lib/i686-pc-cygwin/3.3.1/../../../libbfd.a /usr/lib/gcc-lib/i686-pc-cygwin/
.3.1/../../../libintl.a -L/home/Cliff/cygwin/src/i686-pc-cygwin/libiberty  -libe
ty
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libintl.a(dcigettext.o)(.text+0xa
7): In function `_nl_find_msg':
/usr/src/gettext/gettext-0.12.1/gettext-runtime/intl/dcigettext.c:946: undefined
reference to `_libiconv'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libintl.a(loadmsgcat.o)(.text+0x4
9): In function `_nl_init_domain_conv':
/usr/src/gettext/gettext-0.12.1/gettext-runtime/intl/loadmsgcat.c:863: undefined
reference to `_libiconv_open'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libintl.a(loadmsgcat.o)(.text+0x5
2): In function `_nl_free_domain_conv':
/usr/src/gettext/gettext-0.12.1/gettext-runtime/intl/loadmsgcat.c:896: undefined
reference to `_libiconv_close'
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libintl.a(relocatable.o)(.text+0x
e): In function `libintl_set_relocation_prefix':
/usr/src/gettext/gettext-0.12.1/gettext-runtime/intl/relocatable.c:154: undefine
 reference to `_libiconv_set_relocation_prefix'
collect2: ld returned 1 exit status
make[2]: *** [dumper.exe] Error 1
make[2]: Leaving directory `/home/Cliff/cygwin/src/i686-pc-cygwin/winsup/utils'
make[1]: *** [utils] Error 1
make[1]: Leaving directory `/home/Cliff/cygwin/src/i686-pc-cygwin/winsup'
make: *** [all-target-winsup] Error 2





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

undefined reference problems in cygwin!

[熊光磊]

pgp0.pgp
Description: PGP signature

Re: 20040217 snapshot problem

[Christopher Faylor]

On Wed, Feb 18, 2004 at 11:23:02AM -0500, Richard Campbell wrote:
>> Is this a regression from 20040216 or some other snapshot?
>
>Unless there are earlier post 1.5.7-1 snapshots than 20040205, no.
>
>I just ran through the 20040205-20040216 snapshots:
>
>20040216 - same result as 20040217
>20040215 - exception violation at x0005 or similar.  affects all cygwin programs, 
>not 
>   just XWin.exe
>20040214 - same result as 20040217
>20040213 - same result as 20040217
>20040206 - same result as 20040217
>20040205 - same result as 20040217

Thanks for the details.

Note to any future mailing list archive divers: This is the kind of
detail that I need to debug problems.

When reporting a problem in a snapshot, it is useful to know what you
have run in the past.  If you have the time, then trying older snapshots
to check for regressions is also useful.

--
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: stabilizing cygwin emacs, was: 20040217 snapshot problem

[Thomas L Roche]

Richard Campbell Wed, 18 Feb 2004 10:51:56 -0500 -
> I was trying the 20040217 snapshot to see if it cleared up the emacs
> problems I was having (which haven't been repeatable enough for me
> to report). 

Umm ... what problems?

> After installing the 20040217 snapshot, starting X led to inetd
> consuming all available cpu and no X starting. After shutting down
> inetd, starting X just returned. XWin.exe dropped straight back to a
> command prompt.

> This is repeatable - I've switched cygwin1.dll back and forth from
> 1.5.7-1 to 20040217 snapshot,

Hmm ... I don't recall ever having that problem on either 1.5.7-1 (my
problems have involved emacs crashing after starting, not failing to
start) or 20040217 (on which emacs hasn't crashed yet). Furthermore I
seem to have a configuration similar to yours:

> bash-2.05b$ cygcheck -svr | grep -e 'Windows\|cygwin\|XFree86\|emacs'
> Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3
> OS = `Windows_NT'
>  1096k 2004/02/17 d:\ProgramFiles\Cygwin\bin\cygwin1.dll - os=4.0 
img=1.0 sys=4.0
>   "cygwin1.dll" v0.0 ts=2004/2/17 15:09
> DLL identifier: cygwin1
> Shared id: cygwin1S4
> cygcheck: dump_sysinfo: GetVolumeInformation() failed: 87
> Last downloaded files to: D:\download\cygwin
> Last downloaded files from: ftp://mirrors.rcn.net/pub/sourceware/cygwin
> cygwin  1.5.7-1 
> cygwin-doc  1.3-6 
> emacs   21.2-12 
> emacs-el21.2-12 
> emacs-X11   21.2-12 
> XFree86-base4.3.0-1 
> XFree86-bin 4.3.0-8 
> XFree86-etc 4.3.0-6 
> XFree86-fenc4.2.0-3 
> XFree86-fnts4.2.0-3 
> XFree86-lib 4.3.0-1 
> XFree86-lib-compat  4.3.0-2 
> XFree86-startup-scripts 4.2.0-5 
> XFree86-xserv   4.3.0-44 

Richard Campbell Wed, 18 Feb 2004 10:51:56 -0500
> How best to track this down a little better?

You wanna try debugging emacs? I (and perhaps others :-) could advise
(in my case, out of guilt--I gotta get back to work, so I probably
couldn't start debugging it myself until March).


--
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.7-1: Repeatible crash in cygwin1.dll, _sigbe

[Cliff Geschke]

1.5.7-1: Repeatible crash in cygwin1.dll, _sigbe

cygwin-1.5.7-1
[EMAIL PROTECTED]

After doing what you asked, the crash still occurs, but is somewhat
different.  Here is what I did.

1. Loaded cygwin from CVS.  I see the relevant routines have all changed.
2. ./configure
3. make
4. build failed for dumper.exe (will send separate email)
5. Replaced  /usr/bin/cygwin1.dll with new-cygwin1.dll
6. Reboot (just to be safe)
7. Ran my test program.

I am still seeing stackptr being corrupted.  I believe it happens
after a setjmp/longjump.  See "do_jump" routine below.

I think the problem is in the "call _set_process_mask" in sigreturn.
That somehow winds up calling _sigbe with the thread stack empty.

Look for "" below for start of debug sections.

I can supply the .exe test program if you wish.

Good luck and thanks,

Cliff Geschke


 Here is the program that I think triggers the problem


static void do_jump(
  Context_Control_overlay *currentp,
  Context_Control_overlay *nextp
)
{
  int status;

  if (setjmp(currentp->regs) == 0) {/* Save the current context */
 longjmp(nextp->regs, 0);   /* Switch to the new context */
 _Internal_error_Occurred(
 INTERNAL_ERROR_CORE,
 TRUE,
 status
   );
  }
}


 This shows the crash, but not much info except that stackptr is bad.
 Look at next section for better info.


(gdb) run
Starting program: /home/Cliff/test/ticker/o-optimize/ticker.exe 


*** CLOCK TICK TEST ***
 - rtems_clock_get - 09:00:00   12/31/1988
 - rtems_clock_get - 09:00:05   12/31/1988

Program received signal SIGSEGV, Segmentation fault.
0x in ?? () from 
2: x/i $pc  0x0:Cannot access memory at address 0x0
Disabling display 2 to avoid infinite recursion.
(gdb) bt
#0  0x in ?? () from 
(gdb) info thr
  3 thread 1416.0xeac  0x7ffe0304 in ?? ()
  2 thread 1416.0xc84  0x7ffe0304 in ?? ()
* 1 thread 1416.0x954  0x in ?? () from 
warning: Couldn't restore frame in current thread, at frame 0
0x in ?? () from 
(gdb) info reg
eax0x   -1
ecx0x4  4
edx0x23 2293760
ebx0xa2420d0170139856
esp0xa24163c0xa24163c
ebp0xa2416840xa241684
esi0xdeaddead   -559030611
edi0xdeafdeaf   -558899537
eip0x0  0x0
eflags 0x10246  66118
cs 0x1b 27
ss 0x23 35
ds 0x23 35
es 0x23 35
fs 0x3b 59
gs 0x0  0
(gdb) x/64x 0xa241620
0xa241620:  0x0a2420d0  0x0004  0x0023  0xdeafdeaf
0xa241630:  0x  0x0023  0x  0x0a0301e0
0xa241640:  0x  0x  0x00403859  0x0002
0xa241650:  0x0040b0a0  0x  0x0a2420d0  0xdeaddead
0xa241660:  0x0a2420d0  0x0a241684  0x0040442e  0x
0xa241670:  0x0040b0a0  0x  0x0a2420d0  0xdeaddead
0xa241680:  0xdeafdeaf  0x0a2416a4  0x00409046  0x
0xa241690:  0x  0x  0x  0x
0xa2416a0:  0xfeedfeed  0x0a2416a8  0x00408f60  0x0a2416a8
0xa2416b0:  0x0a2416a8  0x  0x  0x
0xa2416c0:  0x  0x  0x  0x
0xa2416d0:  0x  0x  0x  0x
0xa2416e0:  0x4051  0x0161  0x  0x0008
0xa2416f0:  0x  0x  0x  0x
0xa241700:  0x  0x  0x  0x
0xa241710:  0x  0x  0x  0x
(gdb) p/x *((_cygtls *) (0x23-3744))
$3 = {func = 0x4038a0, saved_errno = 0x4, sa_flags = 0x1000, 
  oldmask = 0x0, newmask = 0xfffbf94f, event = 0x0, errno_addr = 0x22f228, 
  initialized = 0x43227, sigmask = 0x0, sigwait_mask = 0x0, 
  sigwait_info = 0x0, threadkill = 0x0, infodata = {si_signo = 0xe, 
si_code = 0x1, si_pid = 0x588, si_uid = 0x3f0, si_errno = 0x0, {__pad = {
0x72656d, 0x0, 0x244cb8, 0x8cf010, 0x8cf074, 0x610ef79c, 0x77fc49e0, 
0x77f8ee5a, 0x77ed7618, 0xf8eb36, 0x24, 0x8cedc0, 0x0, 0x8cef44, 
0x8cee38, 0x8cee04, 0x, 0x8cef98, 0x77fa88f0, 0x77f511e8, 
0x, 0x77f5f70f, 0x77f60f7f, 0x77d4, 0x8ceecc, 0x0, 
0x8ceee0, 0x1, 0x77e7b36e, 0x77d4, 0x77e7b380, 0x77d4}, 
  si_tid = 0x72656d, si_overrun = 0x0}, si_sigval = {
  sival_int = 0x72656d, sival_ptr = 0x72656d}, si_value = {
  sival_int = 0x72656d, sival_ptr = 0x72656d, {
si_status = 0x72656d, si_utime = 0x0, si_stime = 0x244c

Re: Java Thread Dump in Bash

[Frank-Michael Moser]

Randall R Schulz wrote:
All I said was that cygcheck output would not help me.
Sorry for making trouble misunderstanding this. I have attached my 
cygcheck -s now.



cygcheck.txt
Description: application/force-download
--
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: Assembler

[Krzysztof Duleba]

Williams, Gerald S (Jerry) wrote:

> Googling brought me to http://line.sourceforge.net,
> which may be more along the lines of what you seek.

I tried it out, with no success. Binary version fails to run it's own hello
and rawhello programs and source produces so many serious errors during the
compilation that I have no hope to fix them all. Which doesn't mean that I'm
not trying to :-)

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/

S p a m H o s t i n g - 2 5 0 $

[Marvin Reyna]

Hello.

Spam Hosting.

Location: Korea
OS: FreeBSD
Port: 100mbit.
IP: +
PHP, CGI, MYSQL, 500MB, cPanel.

250$/mesyac.

Fraud Hosting.

Location: Korea
OS: FreeBSD
Port: 100mbit.
IP: +
PHP, CGI, MYSQL, 500MB, cPanel.

450$/mesyac.


Dedicated form 500$ per mounth.


Contacts:
ICQ: 434432


excelling deerskin handclasp backbone lourdes blab cinnabar hysteron infringe isabella 
despair lineup behold 

RE: 20040217 snapshot problem

[Richard Campbell]

> Is this a regression from 20040216 or some other snapshot?

Unless there are earlier post 1.5.7-1 snapshots than 20040205, no.

I just ran through the 20040205-20040216 snapshots:

20040216 - same result as 20040217
20040215 - exception violation at x0005 or similar.  affects all cygwin programs, 
not 
just XWin.exe
20040214 - same result as 20040217
20040213 - same result as 20040217
20040206 - same result as 20040217
20040205 - same result as 20040217

-Richard Campbell.

--
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: select() hangs sometimes, for TCP connections

[Patrick Samson]

I run the process blocking in select() with strace.
It now runs correctly, but the TCL scenario blocks
elsewhere on a "eval exec bash ...".
gdb seems to show a freeze in a call to a
ReadFile() function -> again something with file
descriptors.

So, I put this command in a strace as well.
Guess what, it runs correctly, but...

It fails later on TCL "file delete" with
"permission denied", after around 60 iterations.
I mean the file was deleted so much times without
problem. It even failed during off work hours, so
there is no activity on the PC.
Permissions are not touched.

Here is the last lines (successful) of strace:

12:59:10 [main] pgtclsh 542 normalize_posix_path: src
/home/pgreplicator/data/rbase/euronet.lock
12:59:10 [main] pgtclsh 542 normalize_posix_path:
/home/pgreplicator/data/rbase/euronet.lock =
normalize_posix_path
(/home/pgreplicator/data/rbase/euronet.lock)
12:59:10 [main] pgtclsh 542
mount_info::conv_to_win32_path: conv_to_win32_path
(/home/pgreplicator/data/rbase/euronet.lock)
12:59:10 [main] pgtclsh 542 set_flags: flags: text
(0x200)
12:59:10 [main] pgtclsh 542
mount_info::conv_to_win32_path: src_path
/home/pgreplicator/data/rbase/euronet.lock, dst
D:\cygwin\home\pgreplicator\data\rbase\euronet.lock,
flags 0x208, rc 0
12:59:10 [main] pgtclsh 542 symlink_info::check: not a
symlink
12:59:10 [main] pgtclsh 542 symlink_info::check: 0 =
symlink.check
(D:\cygwin\home\pgreplicator\data\rbase\euronet.lock,
0x2148A0) (0x208)
12:59:10 [main] pgtclsh 542 path_conv::check:
root_dir(D:\),
this->path(D:\cygwin\home\pgreplicator\data\rbase\euronet.lock),
set_has_acls(8)
12:59:10 [main] pgtclsh 542 normalize_posix_path: src
D:/cygwin/home/pgreplicator/data/rbase/euronet.lock
12:59:10 [main] pgtclsh 542 normalize_win32_path:
D:\cygwin\home\pgreplicator\data\rbase\euronet.lock =
normalize_win32_path
(D:/cygwin/home/pgreplicator/data/rbase/euronet.lock)
12:59:10 [main] pgtclsh 542
mount_info::conv_to_win32_path: conv_to_win32_path
(D:/cygwin/home/pgreplicator/data/rbase/euronet.lock)
12:59:10 [main] pgtclsh 542 normalize_win32_path:
D:\cygwin\home\pgreplicator\data\rbase\euronet.lock =
normalize_win32_path
(D:/cygwin/home/pgreplicator/data/rbase/euronet.lock)
12:59:10 [main] pgtclsh 542
mount_info::conv_to_win32_path: src_path
D:/cygwin/home/pgreplicator/data/rbase/euronet.lock,
dst
D:\cygwin\home\pgreplicator\data\rbase\euronet.lock,
flags 0x0, rc 0
12:59:10 [main] pgtclsh 542 symlink_info::check: not a
symlink
12:59:10 [main] pgtclsh 542 symlink_info::check: 0 =
symlink.check
(D:\cygwin\home\pgreplicator\data\rbase\euronet.lock,
0x214770) (0x0)
12:59:10 [main] pgtclsh 542 path_conv::check:
root_dir(D:\),
this->path(D:\cygwin\home\pgreplicator\data\rbase\euronet.lock),
set_has_acls(8)

These calls are caused by the TCL command
"file delete"
So tcl84.dll calls cygwin1.dll for some part of the
work (may be Tcl_FSConvertToPathType()).
But as I don't see any trace of unlink (syscalls.cc),
May be TCL calls directly win32 for the final
deletion function.

Anyone to confirm or reject this analysis ?

$ cygcheck /usr/bin/tcl84.dll
D:/cygwin/bin/tcl84.dll
  C:\WINNT\System32\ADVAPI32.DLL
C:\WINNT\System32\ntdll.dll
C:\WINNT\System32\KERNEL32.dll
C:\WINNT\System32\USER32.dll
  C:\WINNT\System32\GDI32.dll
C:\WINNT\System32\RPCRT4.dll
  D:/cygwin/bin\cygwin1.dll

Is there a potential conflict if TCL calls
cygwin1.dll functions *and* something like
DeleteFileA() or DeleteFileW() of the OS ?

--- Patrick Samson wrote:
> Problem: sometimes select() doesn't return.
> 
> Context: I run a DB replication scenario,
> with cron, everything 5 mn. There is no change in
> the
> DB, so the scenario is always the same. Most of the
> time, it works. But eventually, after some time (may
> be some minutes or hours), a process A keeps waiting
> forever in select() for a response on a TCP socket.
> With gdb I can see that the other end B returned in
> its
> ReadCommand() function, meaning it has send its
> response and waits for a new command, so this side
> should be OK.
> 


__
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

--
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: 20040217 snapshot problem

[Christopher Faylor]

On Wed, Feb 18, 2004 at 10:51:56AM -0500, Richard Campbell wrote:
>I was trying the 20040217 snapshot to see if it cleared up the emacs
>problems I was having (which haven't been repeatable enough for me to
>report).  After installing the 20040217 snapshot, starting X led to
>inetd consuming all available cpu and no X starting.  After shutting
>down inetd, starting X just returned.  XWin.exe dropped straight back
>to a command prompt.
>
>This is repeatable - I've switched cygwin1.dll back and forth from
>1.5.7-1 to 20040217 snapshot, and XWin.exe works or doesn't based on
>the dll.
>
>Cygcheck output attached.
>
>How best to track this down a little better?

Is this a regression from 20040216 or some other snapshot?

--
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: Java Thread Dump in Bash

[Randall R Schulz]

Frank-Michael,

At 07:37 2004-02-18, Frank-Michael Moser wrote:
Larry Hall wrote:

OK.  Maybe now it's time for you to look at and follow:
Problem reports:   http://cygwin.com/problems.html
Larry, what was wrong with my mails? Sorry, if..., but...?
I'm reading the mailing list since a long time and thought I would 
follow these guidelines you just mentioned.

What especially do you miss:
-...
- asked whether to send cygcheck - Randall said no.
All I said was that cygcheck output would not help me.


- ...

Please be specific to me, too, tell me what I did wrong and I swear to 
pick it up for the future.

Frank-Michael


Randall Schulz

--
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: good top program for cygwin

[Christopher Faylor]

On Wed, Feb 18, 2004 at 10:24:55AM -0500, Larry Hall wrote:
>Then you either do not have the 'top' that's part of Cygwin or your
>environment is incorrect.  Try installing/upgrading the procps package.
>There's a man page for the Cygwin version of 'top' that comes with this
>package.  I don't know if this will help you with the issue you
>originally had or not but the documentation for Cygwin's 'top' is
>definitely available.

It won't help.  'top' uses /proc to get its info and /proc currently
only has information on cygwin processes.

cgf

>At 09:07 AM 2/18/2004, Simon you wrote:
>>Of course :
>> $ man top
>>No manual entry for top
>>
>>- Original Message - 
>>From: "Larry Hall" <[EMAIL PROTECTED]>
>>To: "Simon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>>Sent: Tuesday, February 17, 2004 6:42 PM
>>Subject: Re: good top program for Cygwin
>>
>>>At 10:32 AM 2/17/2004, Simon you wrote:
Anyone know of a decent top program to run from the command line?  The
one i have with cygwin installation has no help
>>>
>>>
>>>Did you try 'man top'?

--
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: Java Thread Dump in Bash

[Frank-Michael Moser]

Larry Hall wrote:

OK.  Maybe now it's time for you to look at and follow:
Problem reports:   http://cygwin.com/problems.html
Larry, what was wrong with my mails? Sorry, if..., but...?
I'm reading the mailing list since a long time and thought I would 
follow these guidelines you just mentioned.

What especially do you miss:
- was checking the FAQ
- was checking the archive
- was specific, also quoting a very specific thread from the archive 
including an URL
- asked whether to send cygcheck - Randall said no.
- would look into sources if I would know C (actually sometimes I tried 
patching in the dark)
- did not complain that there is a bug which must be fixed
- did not send personal email
- used an instructive subject line
- confined my mail to one problem
- avoided personal detail
...

Please be specific to me, too, tell me what I did wrong and I swear to 
pick it up for the future.

Frank-Michael

--
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: good top program for Cygwin

[Larry Hall]

Then you either do not have the 'top' that's part of Cygwin or your
environment is incorrect.  Try installing/upgrading the procps package.
There's a man page for the Cygwin version of 'top' that comes with this
package.  I don't know if this will help you with the issue you originally
had or not but the documentation for Cygwin's 'top' is definitely available.

Larry


At 09:07 AM 2/18/2004, Simon you wrote:
>Of course :
> $ man top
>No manual entry for top
>
>Simon
>
>- Original Message - 
>From: "Larry Hall" <[EMAIL PROTECTED]>
>To: "Simon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>Sent: Tuesday, February 17, 2004 6:42 PM
>Subject: Re: good top program for Cygwin
>
>
>> At 10:32 AM 2/17/2004, Simon you wrote:
>> 
>> >Anyone know of a decent top program to run from the command line?
>> >The one i have with cygwin installation has no help
>> 
>> 
>> Did you try 'man top'?
>> 
>> 
>> --
>> 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/


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

[Larry Hall]

At 09:04 AM 2/18/2004, Krzysztof Duleba you wrote:
>Williams, Gerald S (Jerry) wrote:
>> By asking for int 0x80 support, you're really asking
>> for the ability to run precompiled Linux applications.
>
>What do you mean by "precompiled"?


He means Linux ix86 binaries running unmodified on Windows.
That was a goal of "LINE" .


--
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: Built GCC 3.3.3 on Cygwin, should I use it?

[Gareth Pearce]

> 
> I am using Cygwin and GCC to become familiar with posix, common unix
> tools, and to learn c and c++ programming (plus learning win32). So I have
> never compiled any of my programs with -mno-cygwin, but I noticed that it
> doesn't work when I use GCC 3.3.3, just as you said it wouldn't (and it
> won't work if I use any posix functions either, no matter what compiler I
> use, right?). 

Basically yes.

> So by installing a newer version I have not lost anything
> but the capability of running my programs on other computers running
> Windows but lacking Cygwin? And the benefit of installing
> is gaining a number of fixes of bugs that I may or may not encounter (I
> have looked at the list of fixes, but haven't gone into great detail)?
> 

You haven’t lost that ability at all since 3.3.1 is still there for you to
use if you need it, as you aimed for.  -mno-cygwin isn’t the only 'special
cygwin' feature though, you may run into others which are not present in the
official gcc release (from memory possibly some gcj issues as most
significant).  But with 3.3.1 to fall back on you'll be fine.  I personally
use a pre-release copy of gcc 3.4 because of its improved c++ support, and
haven’t experienced any cygwin-specific problems in my day-to-day use of it
under cygwin.  I have experienced some bugs, but that’s what I get for using
a pre-release version.

Gareth



--
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: Java Thread Dump in Bash

[Larry Hall]

OK.  Maybe now it's time for you to look at and follow:

Problem reports:   http://cygwin.com/problems.html

Sounds like you have an installation specific problem that you need to 
dig a little deeper to resolve.

Larry


At 06:31 AM 2/18/2004, Frank-Michael Moser you wrote:
>Ha, now I saw a thread dump in bash console. Unfortunately it kills immediately the 
>java app. In RXVT I see a single new line with "i" printed and the app is killed.
>
>My $CYGWIN is "nontsec nosmbntsec". Java is run from SDK as you do. My cygwin is 
>latest, too (just updated again).
>
>Frank-Michael.
>
>Randall R Schulz wrote:
>>Frank-Michael,
>>At 12:09 2004-02-17, Frank-Michael Moser wrote:
>>
>>>Unfortunately neither Ctrl-Break nor Ctrl-Scroll produce a thread dump not in pure 
>>>bash and not in RXVT for me. I'm using latest cygwin and tried JDK 1.4.2_02 and 
>>>1.5.0 beta.
>>>
>>>Also the java applications I tried do not read from standard input.
>>>
>>>What versions (cygwin/java) do you use.
>>
>>Cygwin: Latest "kernel" and latest version of all packages.
>>Java: Latest (specifically, 1.4.2_03); If it might matter, I generally use the 
>>"java" and "javac" commands from the SDK bin, not the "jre" bin. That's the 
>>directory that includes the compiler and related development tools, where as the jre 
>>bin has only the JVM and other runtime resources.
>>By "pure BASH" I take it you mean BASH in a console window, in contrast to an RXVT 
>>window. I do _not_ use the "tty" option in the CYGWIN environment variable. Do you?
>>
>>>Is it worth to send my cygcheck output attached? Should I really expect Ctrl-Break 
>>>to work - this would be great?
>>
>>I expect it to work because it does work for me...
>>Cygcheck output isn't anything I can use for any purpose I can think of in resolving 
>>this discrepancy between how your system and mine behave.
>>
>>>Frank-Michael
>>
>>Randall Schulz
>>
>>>Randall R Schulz wrote:
>>>
Frank-Michael,

CTRL-BREAK produces a thread-dump using the latest Sun JVM on my system when 
launched from BASH. However, if the program is reading standard input from the 
unredirected console, it receives an end-of-file indication on that stream as well.

Randall Schulz

At 03:42 2004-02-17, Frank-Michael Moser wrote:

>Searching the mailing list archive I found that there is an old thread from Dec 
>2000 which exactly describes my problem:
>
>http://sources.redhat.com/ml/cygwin/2000-12/msg00490.html
>
>In short: Using Ctrl-Scroll does not cause a Java program to dump threads as it 
>does in cmd.exe. Unfortunately the thread ended up with some personal strife.
>
>I understand that the signal problem could be by design. But now (3 years later) 
>maybe there are news about this issue? Has someone a way to work around this 
>problem?
>
>Frank-Michael
>>
>>-- 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/
>
>
>-- 
>
>DECODON GmbHphone: +49(0)3834 515231
>W.-Rathenau-Str. 49a  fax: +49(0)3834 515239
>17489 Greifswaldemail: [EMAIL PROTECTED]
>Germany   web:   www.decodon.com
>
>
>
>--
>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/

--
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: 2004-Feb-17 snapshot change ssh option parsing behavior

[David Rothenberger]

Corinna Vinschen wrote:
On Feb 17 16:46, David Rothenberger wrote:

Robert Collins wrote:

you may find that 
ssh somehost -- bin/bash --login -c date
also works.
In fact, I did, and mentioned that in my first email.  Unfortunately, I 
use this with some old Solaris boxes, which require "-login" instead of 
"--login", and

 ssh somehost -- /bin/bash -login -c date

does not work, for some reason.


Huh?  It does for me.
I just tried it again and it definitely does not work for me.  The key is 
to use "-login" and not "--login".  My cygcheck output is attached to the 
initial report if you're interested.  I'm now running the latest CVS, not 
the snapshot, though.

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: Building dll's and executables in same package

[Yaakov Selkowitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charles Wilson wrote:

| Make sure that the dll has executable permissions.
| chmod +x cygclamav-1.dll
(and echo from Volker Zell)
I wish it were that easy, but it's not, and I don't know why.  When I
run install on it, all the executables are 755 as they should be, but I
still get that Windows error.
BTW, I should point out that my other cases I got working, thanks to
your help.  I guess I was just picking the worst examples.  Even fribidi
I got working, by removing acinclude.m4 (which is just a libtool.m4),
following Garret's tip.
I should point out that I have built clamav with static libs and the
executables run fine.  So what else could it be?
Yaakov

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAM34fpiWmPGlmQSMRAri3AJ96d5uWeAIGQzpBuxb4yeIoxoK3twCgr3ft
HjmWH50XlarpHHlxQ1/xHVg=
=izvT
-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: Built GCC 3.3.3 on Cygwin, should I use it?

[Mikael Åsberg]

>> 
>> I've tried to rebuild a number of programs I have written using GCC 3.3.3
>> and
>> every single one of them seem to work as they should. Many of them are
>> Win32
>> GUI programs (written in C++), some are programs using posix functions.
>> 
>> So my question is: What problems can I expect if continue to use GCC
>> 3.3.3?

>Other then dealing with non-standard install locations (probably leading to
>the c++ issue you had), and probably missing cygwin-specific features there
>shouldn't be any 'problems'.  An example of something likely to be missing
>is -mno-cygwin.

Thanks for your quick and helpful reply, Mr Pearce!

The non-standard install location was intentional. I didn't want to overwrite any 
files belong to GCC 3.3.1 so I could still use that at any time, and from some small 
tests I have made, it seems I have managed to leave the GCC 3.3.1 install intact, 
which is what I wanted.

I am using Cygwin and GCC to become familiar with posix, common unix tools, and to 
learn c and c++ programming (plus learning win32). So I have never compiled any of my 
programs with -mno-cygwin, but I noticed that it doesn't work when I use GCC 3.3.3, 
just as you said it wouldn't (and it won't work if I use any posix functions either, 
no matter what compiler I use, right?). So by installing a newer version I have not 
lost anything but the capability of running my programs on other computers running 
Windows but lacking Cygwin? And the benefit of installing
is gaining a number of fixes of bugs that I may or may not encounter (I have looked at 
the list of fixes, but haven't gone into great detail)?

>> Should I go back to GCC 3.3.1 or is it fine to continue to use the later
>> version? Any other drawbacks of this upgrade? Any benefits? If someone
>> would
>> shed some light on this I would be grateful.

>Given you have installed in a separate location it is not like you have any
>problems here, you can use the installed gcc 3.3.1 when you need it - and
>your own built 3.3.3 when you need that.  You haven't 'upgraded' as such
>just installed a newer version as well.

>But given that you don't know why you've installed it, perhaps you just
>shouldn't bother with it.  3.3.3 is mostly a bug fix release relative to
>3.3.1 - go visit gcc.gnu.org to find out what bug fixes have occurred.  Now
>if you haven't experienced the bugs, then there is probably no point for you
>to have a custom build and you should just wait for whenever the cygwin gcc
>maintainer updates the cygwin gcc distribution.  However if a bit of
>research finds that 3.3.3 has something you want then by all means, use it -
>we're not going to stop you.  ... Well okay, I'm not going to stop you.

>Gareth

Regards, Mikael Åsberg


--
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: ftp bug report

[Thomas Mellman]

--- Igor Pechtchanski <[EMAIL PROTECTED]> wrote:

> 0x6100 is the base address for cygwin1.dll, IIRC.


Aha.  Thank you.  I'm still not clear on what happened to
my stack frame for dataconn(), although I can now imagine
what happened to the stack frame entry for the subordinate
fdopen().

Symbol "fdopen" is at 0x40c530 in a file compiled without debugging.

I also don't understand why I couldn't start ftp in gdb.
Do you have any idea?  Perhaps it has something to do terminal
input?  No, I can't see that ...

BTW, what does IIRC mean?



__
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

--
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: Strange group name

[Igor Pechtchanski]

On Wed, 18 Feb 2004, Julian C H Stevens wrote:

> I have installed cygwin 1.5.6(0.108/3/2) and I notice that the files in
> my home directory have a group ownership of "mkgroup-l-d".
>
> I'm new to cygwin, and have installed it as a domain user on a
> workstation running Windows 2000 Professional Ver 5.0 Build 2195 Service
> Pack 4.
>
> Please could someone suggest how this strange group name has got into my
> /etc/group file?

> Thanks,
> Julian.

Julian,

 explains
this somewhat, but should be updated to say that "mkgroup-l-d" means that
the files are owned by a domain group that isn't in your /etc/group, and
that you should run "mkgroup -l -d >> /etc/group" when you're connected to
a domain controller to fix this.  Otherwise, that group name is harmless,
IIRC.  Perhaps Pierre or Corinna could chime in here...
Igor
P.S. Could you please set your mailer to wrap long lines?
-- 
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: ftp bug report

[Christopher Faylor]

On Wed, Feb 18, 2004 at 09:36:58AM -0500, Igor Pechtchanski wrote:
>On Wed, 18 Feb 2004, Thomas Mellman wrote:
>
>> Re: ftp crash
>>   I tried to debug it with gdb but for some reason that I don't
>>   understand, it hangs when run.
>>
>>   Nevertheless, using gdb to get the symbols (which appear to
>>   be correct) and the ftp.exe.stackdump, I believe that I have
>>   localized the problem to the call to dataconn() in recvrequest().
>> [snip]
>>   The funny thing is that the datacon() routine is in ftp.c, at
>>
>>   Local exec file:
>> `/opt/pub/inetutils-1.3.2-25/ftp/ftp.exe', file type pei-i386.
>> Entry point: 0x401000
>> 0x00401000 - 0x0040cb04 is .text
>> 0x0040d000 - 0x0040e280 is .data
>> 0x0040f000 - 0x00411310 is .bss
>> 0x00412000 - 0x00412ba4 is .idata
>>
>>   But the "entry point" for dataconn is somewhere completely different:
>>
>> Exception: STATUS_ACCESS_VIOLATION at eip=610AB030
>> eax=611489F4 ebx=0038 ecx=7070736D edx=611489F4 esi=0A045018 edi=01B0
>> ebp=0022E9E8 esp=0022E9C8 
>> program=D:\Programme\pub\inetutils-1.3.2-25\ftp\ftp.exe
>> cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023
>> Stack trace:
>> Frame Function  Args
>> [snip]
>> 0022EDB8  61086211  (00401083, 00405EDB, 0A044B70, 0001)
>>
>>   ^ - dataconn?
>>   recvrequest - v
>>
>> 0022EE88  00402E15  (00405EDB, 0A045258, 0A044B70, 00405E3C)
>> [snip]
>> End of stack trace (more stack frames may be present)
>>
>>   Or is these frames starting at 0x22edb8 (0x61086211) some kind
>>   of an interrupt?
>>
>>   Oh, perhaps the dataconn stack frame got lost somehow.  Anyway,
>> [strace output snipped]
>
>0x6100 is the base address for cygwin1.dll, IIRC.

True, but that address is in the middle of malloc, which usually means
malloc pool corruption.  That means it's not a cygwin DLL problem per
se.

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: ftp bug report

[Igor Pechtchanski]

On Wed, 18 Feb 2004, Thomas Mellman wrote:

> Re: ftp crash
>   I tried to debug it with gdb but for some reason that I don't
>   understand, it hangs when run.
>
>   Nevertheless, using gdb to get the symbols (which appear to
>   be correct) and the ftp.exe.stackdump, I believe that I have
>   localized the problem to the call to dataconn() in recvrequest().
> [snip]
>   The funny thing is that the datacon() routine is in ftp.c, at
>
>   Local exec file:
> `/opt/pub/inetutils-1.3.2-25/ftp/ftp.exe', file type pei-i386.
> Entry point: 0x401000
> 0x00401000 - 0x0040cb04 is .text
> 0x0040d000 - 0x0040e280 is .data
> 0x0040f000 - 0x00411310 is .bss
> 0x00412000 - 0x00412ba4 is .idata
>
>   But the "entry point" for dataconn is somewhere completely different:
>
> Exception: STATUS_ACCESS_VIOLATION at eip=610AB030
> eax=611489F4 ebx=0038 ecx=7070736D edx=611489F4 esi=0A045018 edi=01B0
> ebp=0022E9E8 esp=0022E9C8 program=D:\Programme\pub\inetutils-1.3.2-25\ftp\ftp.exe
> cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023
> Stack trace:
> Frame Function  Args
> [snip]
> 0022EDB8  61086211  (00401083, 00405EDB, 0A044B70, 0001)
>
>   ^ - dataconn?
>   recvrequest - v
>
> 0022EE88  00402E15  (00405EDB, 0A045258, 0A044B70, 00405E3C)
> [snip]
> End of stack trace (more stack frames may be present)
>
>   Or is these frames starting at 0x22edb8 (0x61086211) some kind
>   of an interrupt?
>
>   Oh, perhaps the dataconn stack frame got lost somehow.  Anyway,
> [strace output snipped]

0x6100 is the base address for cygwin1.dll, IIRC.
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

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

stabilizing cygwin emacs, was: emacs Fatal error 11

[Thomas L Roche]

"Etienne Huot" Wed, 18 Feb 2004 13:05:22 +0100
> I have tried the latest snapshot 20040217, it worked for several
> hours, but now it crashes almost every 2 minutes. I'm gonna switch
> to 20040216 to see what happens.

Well, so far I've had no crashes with 20040217, but obviously I
haven't been running it very long. Something you might want to
consider (I haven't done it, and YMMV) is rebasing:

Thomas L Roche Tue, 3 Feb 2004 16:09:47 -0500
 ~29 Jan I upgraded to cygwin-1.5.6-1, emacs-21.2.1, and whatever
 the latest XFree86 was then, along with the other goodness
 cygwin's setup advised me to get. Since then emacs life has been
 bad[:] emacs windows disappear, apparently randomly, although
 lately I'm convinced that emacs crashes are more likely when I'm
 either resizing or minimizing its windows.

Al Williams 13 Feb 2004 13:18:32 -0800
>>> I was having this problem. Rebasing the Cygwin DLLs seems to have
>>> cleared it up. Install rebase using setup and then exit all Cygwin
>>> stuff (including httpd, etc.). Then open a plain shell (not an
>>> xterm) and enter:

>>> rebaseall -v

Al Williams 16 Feb 2004 17:24:41 -0800
>> Each DLL has a preferred load address. If it can be loaded at that
>> address, fine. If not, Windows will put it at a different address.
>> Apparently (and I don't know this for sure) the Cygwin stuff
>> assumes all DLLs will be at the same address in each process space
>> (as would always be the case in Win98, for example). So if DLLs
>> conflict and are loaded in different order, it is possible for
>> process A to have DLLx at addresss Z and process B has DLLy at the
>> same address and Cygwin apparently detects this and stops.

>> Rebasing moves the DLL load addresses to make this less likely.

>> If you google on:

>> rebaseall cygwin

>> You'll see this is a common issue with certain packages. I don't
>> think it will really hurt anything. If you are really worried, copy
>> all the DLL files under c:\cygwin (or whatever your CYGROOT is)
>> before you start.


--
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: Pserver on cygwin corrupts binary files

[Igor Pechtchanski]

On Wed, 18 Feb 2004, Alejandro Lopez-Valencia wrote:

> On Wed, 18 Feb 2004 11:01:09 +0100, Corinna Vinschen wrote:
>
> >On Feb 17 18:16, Alejandro Lopez-Valencia wrote:
> >> Because when using textmode, cygwin changes the semantics of I/O
> >> functions in the underlying C runtime. It does (and forces) EOL
> >> conversion on all files read and written to the filesystem as well as
> >> *sockets* and *pipes* for all applications compiled with the runtime.
> >
> >Nope.  Sockets reads and writes are always binary.
> >
> >Corinna
>
> Thanks for ether correction. But wasn't that the case a couple of
> years back?

The textmode mount flag affects neither pipes nor sockets, and never did.
There is a "(no)binmode" $CYGWIN setting that affects pipes, but I'm not
sure if it also affects sockets.
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

--
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: Built GCC 3.3.3 on Cygwin, should I use it?

[Gareth Pearce]

> 
> I've tried to rebuild a number of programs I have written using GCC 3.3.3
> and
> every single one of them seem to work as they should. Many of them are
> Win32
> GUI programs (written in C++), some are programs using posix functions.
> 
> So my question is: What problems can I expect if continue to use GCC
> 3.3.3?

Other then dealing with non-standard install locations (probably leading to
the c++ issue you had), and probably missing cygwin-specific features there
shouldn’t be any 'problems'.  An example of something likely to be missing
is -mno-cygwin.

> Should I go back to GCC 3.3.1 or is it fine to continue to use the later
> version? Any other drawbacks of this upgrade? Any benefits? If someone
> would
> shed some light on this I would be grateful.

Given you have installed in a separate location it is not like you have any
problems here, you can use the installed gcc 3.3.1 when you need it - and
your own built 3.3.3 when you need that.  You haven’t 'upgraded' as such
just installed a newer version as well.

But given that you don’t know why you've installed it, perhaps you just
shouldn’t bother with it.  3.3.3 is mostly a bug fix release relative to
3.3.1 - go visit gcc.gnu.org to find out what bug fixes have occurred.  Now
if you haven’t experienced the bugs, then there is probably no point for you
to have a custom build and you should just wait for whenever the cygwin gcc
maintainer updates the cygwin gcc distribution.  However if a bit of
research finds that 3.3.3 has something you want then by all means, use it -
we're not going to stop you.  ... Well okay, I'm not going to stop you.

Gareth



--
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: 20040217 unhoses unzip!

[Christopher Faylor]

On Tue, Feb 17, 2004 at 11:46:15PM -0500, Thomas L Roche wrote:
>On Tue, 17 Feb 2004, Christopher Faylor wrote:
>>> Hmm.  I really don't understand why unless you were unzipping *a lot*
>>> of files with long filenames.  There should have been something like
>>> 32MB of space to waste before you saw the problem.
>
>Igor Pechtchanski Tue, 17 Feb 2004 22:09:51 -0500 (EST) 
>> They were.  1.4G zip archives with tens of thousands of small files, 
>many
>> with path lengths > 1k.
>
>That also explains why the problem only appeared well into a run (30-60
>min), and why it was unreproducible "in the small" (i.e. a testibly-bad
>but sendably-short input). Even our relatively small (~100 MB) base files
>unzip'ed OK throughout.
>
>Hoping this helps emacs, too ... can't see how, other than it's also hot
>for RAM, but one can hope :-)

The memory leak only happens for file names that are greater than ~130
characters or so.

Unless you are doing something with A LOT of files with this
characteristic in emacs, it is not likely that this is the problem.

cgf

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

Re: good top program for Cygwin

[Simon]

Of course :
 $ man top
No manual entry for top

Simon

- Original Message - 
From: "Larry Hall" <[EMAIL PROTECTED]>
To: "Simon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, February 17, 2004 6:42 PM
Subject: Re: good top program for Cygwin


> At 10:32 AM 2/17/2004, Simon you wrote:
> 
> >Anyone know of a decent top program to run from the command line?
> >The one i have with cygwin installation has no help
> 
> 
> Did you try 'man top'?
> 
> 
> --
> 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: Assembler

[Krzysztof Duleba]

Williams, Gerald S (Jerry) wrote:

> int 0x80 is part of Linux, not nasm.

Of course.

> In fact, nasm was
> generating the int 0x80 instructions just fine--they
> simply don't work under Windows. So such a translator
> wouldn't help.

A translator that changes int 0x80 to function calls? It doesn't seem too
difficult, but I probably miss something.

The way I think is: if in Linux it is possible to translate function calls
to int 0x80, one could build a funcion call -> int 0x80 dictionary. If the
dictionary is complete (or at least big enough), having a int 0x80-like
system call one can look up the corresponding funcion call.

> By asking for int 0x80 support, you're really asking
> for the ability to run precompiled Linux applications.

What do you mean by "precompiled"?

> Googling brought me to http://line.sourceforge.net,
> which may be more along the lines of what you seek.

I will check it out right away. 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/

Built GCC 3.3.3 on Cygwin, should I use it?

[Mikael Åsberg]

Hello, I downloaded GCC 3.3.3, built it using GCC 3.3.1 that comes
with Cygwin.
My configure line was:
$ ../gcc-3.3.3/./configure --enable-languages=c,c++ --prefix=/usr/local/gcc-3.3.3 
--exec-prefix=/usr/local/gcc-3.3.3

The configure script, make and make install finsihed without any errors.

When I do: $ /usr/local/gcc-3.3.3/bin/gcc --version the output is:
gcc (GCC) 3.3.3
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /usr/local/gcc-3.3.3/bin/g++ --version yields:
g++ (GCC) 3.3.3
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

When I build C++ programs using GCC 3.3.3, I specify: "-L /usr/local/gcc-3.3.3/lib/",
or else I would get errors linking.
When I build C programs, that doesn't seem to be necessary (why?).

I've tried to rebuild a number of programs I have written using GCC 3.3.3 and
every single one of them seem to work as they should. Many of them are Win32
GUI programs (written in C++), some are programs using posix functions.

So my question is: What problems can I expect if continue to use GCC 3.3.3?
Should I go back to GCC 3.3.1 or is it fine to continue to use the later 
version? Any other drawbacks of this upgrade? Any benefits? If someone would
shed some light on this I would be grateful.
I don't want to break things in Cygwin and get all kinds of weird errors
but at the same time it feels good to use the latest official gcc release.

Thanks for any replies


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

[Krzysztof Duleba]

Igor Pechtchanski wrote:

> Most of the C code on Linux doesn't use int 0x80.  It normally invokes
> user-level functions that invoke system calls.
>  Why not go the same route
> with Cygwin?  In one of the previous messages in this thread, there was an
> example of calling printf from assembly.  You should be able to make calls
> to the Cygwin emulation layer the same way.

The syntax is not up to me.

>From your answers, I still don't know whether using int 0x80 in Cygwin is
impossile (directly) or not. If Nasm (I'm limited to this assembler) can't
generate proper executables that would work with Cygwin, then what should I
look for? I guess that some kind of translator that changes expressions like

mov eax, 4
int 0x80

into

call _write

(with proper arguments) has already been created. I don't know where to
start searching, though. But if not, is there any point to start such a
project? Do you think it is possible to be more or less working in, let's
say, half a year?

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/

Strange group name

[Julian C H Stevens]

I have installed cygwin 1.5.6(0.108/3/2) and I notice that the files in my home 
directory have a group ownership of "mkgroup-l-d".
I'm new to cygwin, and have installed it as a domain user on a workstation running 
Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4.
Please could someone suggest how this strange group name has got into my /etc/group 
file?
Thanks,
Julian.

_
Get Paid to Surf the Web!
http://www.alladvantage.com/home.asp?refid=AVZ855

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

[Williams, Gerald S (Jerry)]

Krzysztof Duleba wrote:
> Why not? c code, translated to asm with -c -S on linux box, 
> can be later compiled and linked with Cygwin's gcc and works
> fine. As you see, I have a good reason to believe that nasm's
> int 0x80 will work too. So maybe I should simply look for a
> nasm -> gcc's assembler translator?

int 0x80 is part of Linux, not nasm. In fact, nasm was
generating the int 0x80 instructions just fine--they
simply don't work under Windows. So such a translator
wouldn't help.

Cygwin does a great job translating many of the system
calls, but these are invoked via function calls, not
Linux internal software interrupts.

By asking for int 0x80 support, you're really asking
for the ability to run precompiled Linux applications.
Googling brought me to http://line.sourceforge.net,
which may be more along the lines of what you seek.

-Jerry

--
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: Building dll's and executables in same package

[Dr. Volker Zell]

--- Begin Message ---
> "Yaakov" == Yaakov Selkowitz writes:

Yaakov> OK, here's the story.  I built clamav after the following steps, and
Yaakov> everything completed without errors, and cygcheck shows the applications
Yaakov> are linked to cygclamav-1.dll.  But when I try running one of the
Yaakov> programs that were built, I get a Windows error dialog:

Yaakov> freshclam.exe - Application Error

Yaakov> ~  The application failed to initialize properly (0xc005).  Click on
Yaakov> OK to terminate the application.

Yaakov> This happens by all of the applications, even when I moved
Yaakov> cygclamav-1.dll into my PATH, and even if I call the programs with
Yaakov> - --help or --version options.  What's going on now??

It happened to me too sometimes. Check the permissions on the dll's
sometimes they do not have the execute permission. Don't know why so.

Yaakov> Yaakov

Ciao
  Volker

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

Mirror server - ftp.heanet.ie/pub/cygwin

[Brian Boyle]

Hi,

We've been mirroring the Cygwin repository for a while now, and thought
it might be useful to let you guys know. It is available at:

(ftp|http|rsync)://ftp.heanet.ie/pub/cygwin

on both ipv4 and ipv6. It gets updated twice a day, and the status and
time of the most recent sync can be observed at:

http://ftp.heanet.ie/status/

More information on the system hosting the mirror is available for those
who are interested is available at:

http://ftp.heanet.ie/about/

Best regards,
Brian.
-- 
Brian Boyle Phone:  +353-1-660-9040
Managed Network ServicesFax:+353-1-660-3666
HEAnet Limited  Email:  [EMAIL PROTECTED]

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

Re: Re: emacs Fatal error 11

[Etienne Huot]

References: <[EMAIL PROTECTED]>

I have tried the latest snapshot 20040217, it worked for several hours,
but now it crashes almost every 2 minutes. I'm gonna switch to 20040216
to see what happens. 

>The 1.5.7 cygwin1.dll is buggy. Load the latest DLL snapshot (20040216)
>from http://cygwin.com/snapshots/ . I've worked with it (i.e Emacs) for
>few hours now and it seems stable.
>
>Ehud.



--
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: Pserver on cygwin corrupts binary files

[Alejandro Lopez-Valencia]

On Wed, 18 Feb 2004 11:01:09 +0100, Corinna Vinschen wrote in
<[EMAIL PROTECTED]>:

>On Feb 17 18:16, Alejandro Lopez-Valencia wrote:
>> Because when using textmode, cygwin changes the semantics of I/O
>> functions in the underlying C runtime. It does (and forces) EOL
>> conversion on all files read and written to the filesystem as well as
>> *sockets* and *pipes* for all applications compiled with the runtime.
>
>Nope.  Sockets reads and writes are always binary.
>
>Corinna

Thanks for ether correction. But wasn't that the case a couple of
years back?



--
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: new to cygwin, not understanding a setup issue...

[Thorsten Kampe]

* Adam Reiswig (2004-02-18 01:45 +0100)
> Hello, I am new to cygwin.  I am running a windows 2000 machine.  I just 
> finished downloading and installing cygwin.  When the setup finished I 
> ran the Cygwin icon on my desktop, got the bash prompt and every command 
> I type comes back "command not found".  The head of the bash window 
> reads "bash: /etc/profiles: Permission denied".

The path isn't set - same as in Windows. Try "/bin/ls" instead of
"ls". The path is set in /etc/profile.

> Is there a cygwin for dummies out there somewhere??

The FAQ and the user manual. You'll find them on your own, won't you?


--
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: Java Thread Dump in Bash

[Frank-Michael Moser]

Ha, now I saw a thread dump in bash console. Unfortunately it kills 
immediately the java app. In RXVT I see a single new line with "i" 
printed and the app is killed.

My $CYGWIN is "nontsec nosmbntsec". Java is run from SDK as you do. My 
cygwin is latest, too (just updated again).

Frank-Michael.

Randall R Schulz wrote:
Frank-Michael,

At 12:09 2004-02-17, Frank-Michael Moser wrote:

Unfortunately neither Ctrl-Break nor Ctrl-Scroll produce a thread dump 
not in pure bash and not in RXVT for me. I'm using latest cygwin and 
tried JDK 1.4.2_02 and 1.5.0 beta.

Also the java applications I tried do not read from standard input.

What versions (cygwin/java) do you use.


Cygwin: Latest "kernel" and latest version of all packages.
Java: Latest (specifically, 1.4.2_03); If it might matter, I generally 
use the "java" and "javac" commands from the SDK bin, not the "jre" bin. 
That's the directory that includes the compiler and related development 
tools, where as the jre bin has only the JVM and other runtime resources.

By "pure BASH" I take it you mean BASH in a console window, in contrast 
to an RXVT window. I do _not_ use the "tty" option in the CYGWIN 
environment variable. Do you?


Is it worth to send my cygcheck output attached? Should I really 
expect Ctrl-Break to work - this would be great?


I expect it to work because it does work for me...

Cygcheck output isn't anything I can use for any purpose I can think of 
in resolving this discrepancy between how your system and mine behave.


Frank-Michael


Randall Schulz


Randall R Schulz wrote:

Frank-Michael,

CTRL-BREAK produces a thread-dump using the latest Sun JVM on my 
system when launched from BASH. However, if the program is reading 
standard input from the unredirected console, it receives an 
end-of-file indication on that stream as well.

Randall Schulz

At 03:42 2004-02-17, Frank-Michael Moser wrote:

Searching the mailing list archive I found that there is an old 
thread from Dec 2000 which exactly describes my problem:

http://sources.redhat.com/ml/cygwin/2000-12/msg00490.html

In short: Using Ctrl-Scroll does not cause a Java program to dump 
threads as it does in cmd.exe. Unfortunately the thread ended up 
with some personal strife.

I understand that the signal problem could be by design. But now (3 
years later) maybe there are news about this issue? Has someone a 
way to work around this problem?

Frank-Michael


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


--

DECODON GmbHphone: +49(0)3834 515231
W.-Rathenau-Str. 49a  fax: +49(0)3834 515239
17489 Greifswaldemail: [EMAIL PROTECTED]
Germany   web:   www.decodon.com

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

ftp bug report

[Thomas Mellman]

Re: ftp crash

  ftp crashes intermittently (but reliably) when getting files.
  I tried to debug it with gdb but for some reason that I don't
  understand, it hangs when run.

  Nevertheless, using gdb to get the symbols (which appear to
  be correct) and the ftp.exe.stackdump, I believe that I have
  localized the problem to the call to dataconn() in recvrequest().

  Note that I am using case and nmap (nmap $1;$2 $1) but I think
  that's not a requirement.

  The funny thing is that the datacon() routine is in ftp.c, at

  Local exec file:
`/opt/pub/inetutils-1.3.2-25/ftp/ftp.exe', file type pei-i386.
Entry point: 0x401000
0x00401000 - 0x0040cb04 is .text
0x0040d000 - 0x0040e280 is .data
0x0040f000 - 0x00411310 is .bss
0x00412000 - 0x00412ba4 is .idata

  But the "entry point" for dataconn is somewhere completely different:


Exception: STATUS_ACCESS_VIOLATION at eip=610AB030
eax=611489F4 ebx=0038 ecx=7070736D edx=611489F4 esi=0A045018 edi=01B0
ebp=0022E9E8 esp=0022E9C8 program=D:\Programme\pub\inetutils-1.3.2-25\ftp\ftp.exe
cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023
Stack trace:
Frame Function  Args
0022E9E8  610AB030  (611489C0, 0001201F, 0024E530, 0200)
0022EA28  610AAE17  (, 0001, 0022EA78, 61054EA8)
0022EA38  610AB4E5  (74F41678, , 0022EAE4, 74F46C93)
0022EA78  61054EA8  (0001, 3028, 0022EAC8, 61082BB0)
0022EA88  61001CA9  (3028, 0022EBA0, 0022EBE8, 0024E530)
0022EAC8  61082BB0  (0A045280, 0022ECD0, 0022EF68, 74FAE1D5)
0022EC18  6107FA26  (0022ECD0, 0022EC64, 0022EC54, 0022EC44)
0022ED28  6107F3AB  (0006, 0022ED50, 0022EC84, 0022EC74)
0022ED78  6105BE38  (0005, 0022EDA0, 0022ED9C, 00401923)
0022EDB8  61086211  (00401083, 00405EDB, 0A044B70, 0001)

  ^ - dataconn?
  recvrequest - v

0022EE88  00402E15  (00405EDB, 0A045258, 0A044B70, 00405E3C)
0022EEB8  00406462  (0002, 00410F00, 611102A8, 0001)
0022EED8  0040A8B2  (0001, 0040A6A0, 0040A1F8, 0040E100)
0022EF40  0040A61D  (0001, 616733D4, 0A0400A8, 0022EF98)
0022EF80  61005DE0  (0022EF98, , , )
0022FF90  61005EE5  (, , , )
End of stack trace (more stack frames may be present)


  Or is these frames starting at 0x22edb8 (0x61086211) some kind
  of an interrupt?


  Oh, perhaps the dataconn stack frame got lost somehow.  Anyway,
  I now have an strace output which I will be glad to provide.
  The last lines are:


  186 1454434 [main] ftp 1472 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 
0x1
  147 1454581 [main] ftp 1472 fhandler_base::set_flags: filemode set to binary
  147 1454728 [main] ftp 1472 fdsock: fd 4, name '', soc 0x218
  161 1454889 [main] ftp 1472 cygwin_socket: 4 = socket (2, 1, 0)
  397 1455286 [main] ftp 1472 cygwin_bind: 0 = bind (4, 0x40F390, 16)
  336 1455622 [main] ftp 1472 cygwin_getsockname: 0 = getsockname (4, 0x40F390, 
0x22EC80)
  266 1455888 [main] ftp 1472 cygwin_listen: 0 = listen (4, 1)
  155 1456043 [main] ftp 1472 void: 0x402A90 = signal (2, 0x401770)
  172 1456215 [main] ftp 1472 writev: writev (3, 0x22EB90, 1)
  160 1456375 [main] ftp 1472 wsock_event::prepare: 2288292 = wsock_event::prepare ()
  210 1456585 [main] ftp 1472 writev: 26 = write (3, 0x22EB90, 1), errno 2
  351 1456936 [main] ftp 1472 void: 0x401770 = signal (2, 0x401770)
  159 1457095 [main] ftp 1472 readv: readv (3, 0x22EB40, 1) blocking, sigcatchers 2
  146 1457241 [main] ftp 1472 readv: no need to call ready_for_read
  153 1457394 [main] ftp 1472 wsock_event::prepare: 2288196 = wsock_event::prepare ()
 1060 1458454 [main] ftp 1472 readv: 30 = readv (3, 0x22EB40, 1), errno 2
  198 1458652 [main] ftp 1472 void: 0x401770 = signal (2, 0x401770)
  132 1458784 [main] ftp 1472 void: 0x401770 = signal (2, 0x402A90)
  145 1458929 [main] ftp 1472 void: 0x402A90 = signal (2, 0x401770)
  144 1459073 [main] ftp 1472 writev: writev (3, 0x22EBE0, 1)
  137 1459210 [main] ftp 1472 wsock_event::prepare: 2288372 = wsock_event::prepare ()
  219 1459429 [main] ftp 1472 writev: 19 = write (3, 0x22EBE0, 1), errno 2
  200 1459629 [main] ftp 1472 void: 0x401770 = signal (2, 0x401770)
  152 1459781 [main] ftp 1472 readv: readv (3, 0x22EB90, 1) blocking, sigcatchers 2
  159 1459940 [main] ftp 1472 readv: no need to call ready_for_read
  152 1460092 [main] ftp 1472 wsock_event::prepare: 2288276 = wsock_event::prepare ()
39176 1499268 [main] ftp 1472 readv: 101 = readv (3, 0x22EB90, 1), errno 2
  361 1499629 [main] ftp 1472 void: 0x401770 = signal (2, 0x401770)
  138 1499767 [main] ftp 1472 void: 0x401770 = signal (2, 0x402A90)
  137 1499904 [main] ftp 1472 writev: writev (2, 0x22EC60, 1)
  146 1500050 [main] ftp 1472 fhandler_base::write: binary write
entered dataconn
^@  214 1500264 [main] ftp 1472 fhandler_base::write: 18 = write (0x403C44, 18)
  147 1500411 [main] ftp 1472 wri

Re: 2004-Feb-17 snapshot change ssh option parsing behavior

[Corinna Vinschen]

On Feb 17 16:46, David Rothenberger wrote:
> Robert Collins wrote:
> >you may find that 
> >ssh somehost -- bin/bash --login -c date
> >also works.
> 
> In fact, I did, and mentioned that in my first email.  Unfortunately, I 
> use this with some old Solaris boxes, which require "-login" instead of 
> "--login", and
> 
>   ssh somehost -- /bin/bash -login -c date
> 
> does not work, for some reason.

Huh?  It does for me.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[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/

Re: Pserver on cygwin corrupts binary files

[Corinna Vinschen]

On Feb 17 18:16, Alejandro Lopez-Valencia wrote:
> Because when using textmode, cygwin changes the semantics of I/O
> functions in the underlying C runtime. It does (and forces) EOL
> conversion on all files read and written to the filesystem as well as
> *sockets* and *pipes* for all applications compiled with the runtime.

Nope.  Sockets reads and writes are always binary.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[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/

Re: setup "base": strange behaviour of libbz2-1 and libpcre

[fergus]

> In my TODO to review ...

Thanks. Everybody is so busy, it's amazing you all do even half of what you
actually do do.
Fergus


--
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: setup "base": strange behaviour of libbz2-1 and libpcre

[Robert Collins]

On Wed, 2004-02-18 at 19:11, [EMAIL PROTECTED] wrote:
> Sorry, I know this has been asked a while ago but I can't find the Q and I'm
> pretty certain there wasn't an A.

In my TODO to review. slated for early march (I'm in a huge transition
point at the moment).

Rob

-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: problem extending perl-5.8.2-1 via CPAN: Storable.dll

[Olaf Föllinger]

On Tue, Feb 17, 2004 at 09:26:42PM -0500, S. Alan Ezust wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I was having some strange problems with CPAN as well - has anyone ever tried 
> running a perl script that uses HTML::Parser or HTML::Filter by installing 
> through the CPAN that comes with cygwin? I have a script that runs fine under 
> linux and activeperl for windows, but doesn't under cygwin/perl. 

Yes, me.
 
Gruss Olaf Föllinger

-- 
Olaf Föllinger
Berater 
S.E.S.A. Software und Systeme AG


--
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 extending perl-5.8.2-1 via CPAN: Storable.dll

[Olaf Föllinger]

On Tue, Feb 17, 2004 at 07:09:19PM +0100, Tino Lange wrote:
> Gerrit P. Haase wrote:
> >perl-5.8.2-1 release has been uploaded to sourceware
> >   -- it should be on the mirrors soon.
> 
> Hi Gerrit, hi List!
> 
> I have a problem updating modules within the CPAN Shell. Perl itself 
> crashes due to problems with Storable.dll?

I'm not Gerrit neither the list but it works fine here except for some
tests which don't pass. 
 
Gruss Olaf Föllinger

-- 
Olaf Föllinger
Berater 
S.E.S.A. Software und Systeme AG


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

piping problems with cron+4nt

[Mironov, Leonid {PBG}]

I've got a bunch of legacy 4NT batches I want to run from cygwin cron. When
run from 4NT started from bash these batches work fine but when started from
cron all lines with redirection and piping fail, e.g. when I run

   dir>q

file 'q' is not created,

   dir|sort

starts sort and it sits and waits for keyboard input. Also output from
external programs is lost, e.g. if batch looks like

   echo zzz
   zip zzz *
   echo qqq

and is run as 

0   2   *   *   *   4NT.EXE /c
ibackup.btm>>h:\\backup\\bk.log

file h:\backup\bk.log will look like

   zzz
   qqq

zip output is missing, although zip archive is created.

Any ideas?

Win XP SP1, just refreshed cygwin and 4NT to latest bulds whith no effect at
all.

:), Leo


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

setup "base": strange behaviour of libbz2-1 and libpcre

[fergus]

Sorry, I know this has been asked a while ago but I can't find the Q and I'm
pretty certain there wasn't an A.
1. Choose default "base" setup from internet and run to completion. 2.
Immediately choose it again and two new packages are identified for
installation: libbz2_1-1.0.2-5 and libpcre0-4.5-1. Is there a reason why
these two are not selected and installed at run 1? I tried looking at
setup.ini but found nothing exceptionable.
Fergus


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