Re: 1.5.8s: make hangs on XP (with HT)

[Rolf Campbell]

Rafael Kitover wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Rolf Campbell
Sent: Thursday, February 05, 2004 8:40 AM
To: [EMAIL PROTECTED]
Subject: 1.5.7: make hangs on XP (with HT)
I've been trying to narrow the problem I've been having with make (-j)
and processes locking up.  And I've made some progress.
First, this happens with 1.5.6 -> 1.5.7 (and every snapshot in-between).

I've tried this test on 3 configurations:
WinXP (HyperThreaded): fails quickly (between 20 seconds and 3 minutes)
Win2000 (Not HT): fails slowly (between 6 minutes and 20 minutes)
WinXP (HT turned off): does not fail (ran it for about an hour and it
was fine).
[SNIP]

This test would fail on me on WinXP on an HT machine very quickly with 1.5.7
and earlier snapshot, but with the most recent CVS it works fine :)
I tried the Feb05 snapshot, and things are MUCH better.  Instead of 
failing after 1 to 36 iterations, it now lasts into the hundreds, but it 
still does eventually fail.  On iteration #337 (about 20 minutes in), I 
got a similar strace output:

And, like before, after this output, the process continued to run, 
consuming as much processor time as it could.

  186 1375242 [main] sh 10144 __to_clock_t: dwHighDateTime 0, 
dwLowDateTime 0
   47 1375289 [main] sh 10144 __to_clock_t: total  
   48 1375337 [main] sh 10144 __to_clock_t: dwHighDateTime 0, 
dwLowDateTime 312500
   46 1375383 [main] sh 10144 __to_clock_t: total  001F
 -178 1375205 [sig] sh 10144 wait_sig: done
 1642 1376847 [sig] sh 10144 _threadinfo::remove: wait 0x0
  147 1376994 [main] sh 10144 _pinfo::exit: Calling ExitProcess 0
20174 4390513 [proc] make 3748 proc_subproc: args: 2, 0
   82 4390595 [proc] make 3748 proc_subproc: pid 10144[0] terminated, 
handle 0x650, nchildren 1, nzombies 8
   50 4390645 [proc] make 3748 proc_subproc: zombifying [0], pid 10144, 
handle 0x650, nchildren 1
   51 4390696 [proc] make 3748 proc_subproc: returning 1
   50 4390746 [proc] make 3748 sig_send: sendsig 0x714, pid 3748, 
signal 20, its_me 1
   62 4390808 [proc] make 3748 sig_send: Not waiting for sigcomplete. 
its_me 1 signal 20
   44 4390852 [proc] make 3748 sig_send: returning 0x0 from sending 
signal 20
  171 4391023 [proc] make 3748 wait_subproc: looping
9 4391032 [sig] make 3748 sigpacket::process: signal 20 processing
  109 4391141 [sig] make 3748 _threadinfo::find_tls: sig 20
   51 4391192 [sig] make 3748 sigpacket::process: signal 20, about to 
call 0x40C540
   49 4391241 [sig] make 3748 setup_handler: suspending mainthread
   80 4391321 [sig] make 3748 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   54 4391375 [sig] make 3748 setup_handler: couldn't interrupt. 
trying again.
   60 4391435 [sig] make 3748 setup_handler: suspending mainthread
   72 4391507 [sig] make 3748 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   55 4391562 [sig] make 3748 setup_handler: couldn't interrupt. 
trying again.
   62 4391624 [sig] make 3748 setup_handler: suspending mainthread
  135 4391759 [sig] make 3748 interruptible: pc 0x77E66B4A, h 
0x77E6, interruptible 0
   50 4391809 [sig] make 3748 setup_handler: couldn't interrupt. 
trying again.
   63 4391872 [sig] make 3748 setup_handler: suspending mainthread
   68 4391940 [sig] make 3748 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   54 4391994 [sig] make 3748 setup_handler: couldn't interrupt. 
trying again.
   80 4392074 [sig] make 3748 setup_handler: suspending mainthread
   70 4392144 [sig] make 3748 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   51 4392195 [sig] make 3748 setup_handler: couldn't interrupt. 
trying again.
   63 4392258 [sig] make 3748 setup_handler: suspending mainthread
   68 4392326 [sig] make 3748 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   75 4392401 [sig] make 3748 setup_handler: couldn't interrupt. 
trying again.
   62 4392463 [sig] make 3748 setup_handler: suspending mainthread
   69 4392532 [sig] make 3748 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   52 4392584 [sig] make 3748 setup_handler: couldn't interrupt. 
trying again.
   60 4392644 [sig] make 3748 setup_handler: suspending mainthread
   67 4392711 [sig] make 3748 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   51 4392762 [sig] make 3748 setup_handler: couldn't interrupt. 
trying again.
   52 4392814 [sig] make 3748 setup_handler: suspending mainthread
   67 4392881 [sig] make 3748 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   42 4392923 [sig] make 3748 setup_handler: couldn't interrupt. 
trying again.
   48 4392971 [sig] make 3748 setup_handler: suspending mainthread
   57 4393028 [sig] make 3748 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
  104 4393132 [sig] make 3748 setup_handler: couldn't interrupt. 
trying again.
   48 4393180 [sig

1.5.7: make hangs on XP (with HT)

[Rolf Campbell]

I've been trying to narrow the problem I've been having with make (-j) 
and processes locking up.  And I've made some progress.

First, this happens with 1.5.6 -> 1.5.7 (and every snapshot in-between).

I've tried this test on 3 configurations:
WinXP (HyperThreaded): fails quickly (between 20 seconds and 3 minutes)
Win2000 (Not HT): fails slowly (between 6 minutes and 20 minutes)
WinXP (HT turned off): does not fail (ran it for about an hour and it 
was fine).

I started stracing the output, and I cannot attach the entire list (it's 
40MB), but I'll give you a portion that shows the problem:

After the end of this strace, the process still exists (consuming as 
much of the CPU as it can).

I'm guessing the problem is:
   61 6410845 [sig] make 2328 setup_handler: couldn't interrupt. 
trying again.

Does anyone know what would cause that problem?

--strace tail--

   97 6402963 [main] make 608! __to_clock_t: dwHighDateTime 0, 
dwLowDateTime 312500
   69 6403032 [main] make 608! __to_clock_t: total  001F
   64 6403096 [main] make 608! __to_clock_t: dwHighDateTime 0, 
dwLowDateTime 156250
   67 6403163 [main] make 608! __to_clock_t: total  000F
 2062 6405225 [main] make 608! _pinfo::exit: Calling ExitProcess 131072
 29815968 [main] sh 608 sigaction: signal 2, newact 0x0, oldact 
0x22EDC0
   736041 [main] sh 608 void: 0x0 = signal (2, 0x40F5A0)
   666107 [main] sh 608 sigaction: signal 3, newact 0x0, oldact 
0x22EDC0
   586165 [main] sh 608 void: 0x0 = signal (3, 0x40F5A0)
   476212 [main] sh 608 sigaction: signal 15, newact 0x0, oldact 
0x22EDC0
   496261 [main] sh 608 void: 0x0 = signal (15, 0x0)
   746335 [main] sh 608 cwdstuff::get: posix /tmp
   576392 [main] sh 608 cwdstuff::get: (/tmp) = cwdstuff::get 
(0x22DE10, 4096, 1, 1), errno 0
32455 6406299 [proc] make 2328 proc_subproc: args: 2, 0
  120 6406419 [proc] make 2328 proc_subproc: pid 608[0], reparented old 
hProcess 0x658, new 0x6A4
  101 6406520 [proc] make 2328 proc_subproc: returning 0
  5666958 [main] sh 608 do_exit: do_exit (0), exit_state 0
  104 6406624 [proc] make 2328 wait_subproc: looping
  1007058 [main] sh 608 void: 0x0 = signal (20, 0x1)
   567114 [main] sh 608 void: 0x0 = signal (1, 0x1)
   507164 [main] sh 608 void: 0x40F5A0 = signal (2, 0x1)
   707234 [main] sh 608 void: 0x40F5A0 = signal (3, 0x1)
   917325 [main] sh 608 sigproc_terminate: entering
   767401 [main] sh 608 proc_terminate: nchildren 0, nzombies 0
17402 [sig] sh 608 wait_sig: done
   587460 [main] sh 608 proc_terminate: leaving
   517511 [sig] sh 608 _threadinfo::remove: wait 0x0
  1887699 [main] sh 608 __to_clock_t: dwHighDateTime 0, 
dwLowDateTime 156250
   547753 [main] sh 608 __to_clock_t: total  000F
   527805 [main] sh 608 __to_clock_t: dwHighDateTime 0, 
dwLowDateTime 156250
   477852 [main] sh 608 __to_clock_t: total  000F
 15499401 [main] sh 608 _pinfo::exit: Calling ExitProcess 0
 3488 6410112 [proc] make 2328 proc_subproc: args: 2, 0
   89 6410201 [proc] make 2328 proc_subproc: pid 608[0] terminated, 
handle 0x6A4, nchildren 1, nzombies 1
   59 6410260 [proc] make 2328 proc_subproc: zombifying [0], pid 608, 
handle 0x6A4, nchildren 1
   62 6410322 [proc] make 2328 proc_subproc: returning 1
   59 6410381 [proc] make 2328 sig_send: sendsig 0x710, pid 2328, 
signal 20, its_me 1
   74 6410455 [proc] make 2328 sig_send: Not waiting for sigcomplete. 
its_me 1 signal 20
7 6410462 [sig] make 2328 sig_handle: signal 20 processing
   48 6410510 [proc] make 2328 sig_send: returning 0x0 from sending 
signal 20
   62 6410572 [sig] make 2328 sig_handle: signal 20, about to call 0x40C540
   48 6410620 [proc] make 2328 wait_subproc: looping
   46 6410666 [sig] make 2328 setup_handler: suspending mainthread
  118 6410784 [sig] make 2328 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   61 6410845 [sig] make 2328 setup_handler: couldn't interrupt. 
trying again.
   76 6410921 [sig] make 2328 setup_handler: suspending mainthread
   69 6410990 [sig] make 2328 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   56 6411046 [sig] make 2328 setup_handler: couldn't interrupt. 
trying again.
   73 649 [sig] make 2328 setup_handler: suspending mainthread
   68 6411187 [sig] make 2328 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   52 6411239 [sig] make 2328 setup_handler: couldn't interrupt. 
trying again.
   75 6411314 [sig] make 2328 setup_handler: suspending mainthread
   73 6411387 [sig] make 2328 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   63 6411450 [sig] make 2328 setup_handler: couldn't interrupt. 
trying again.
   76 6411526 [sig] make 2328 setup_handler: suspending mainthread
   65 6411591 [sig] make 2328 interruptible: pc 0x7FFE0304, h 
0x7FFE, interruptible 0
   52 6411643 [sig] make 2328 setup_handler: couldn't interrupt. 
tr

Re: strange thing for execlp() function

[Rolf Campbell]

kaiduan xie wrote:
Hi,all,

I just want to use execlp to invoke another program
from a program. It works on Linux, but it stucks on
Cygwin. Acutally, this is a very very very simple
program:
#include 
#include 
#include 
#include 
#include 
int main()
{
pid_t pid;

printf("Hello, cygwin!\n");
if (execlp("/home/kaiduan/test2.exe",
"test2.exe",(char *)0) < 0)
printf("Error is %s\n", strerror(errno));
}
I also added current directy to PATH, but it still
sucks. Anything wrong?
Yes, there is something wrong.  You haven't said what the problem is 
(other than it sucking).  This program works fine for me if i change the 
line to "/bin/ls.exe".

--
Unsubscribe info:  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: printf does not print long long ints properly

[Rolf Campbell]

"ll" is the long long prefix.

Daniel Jeliński wrote:
when I compile the following program:

#include 
main()
{
long long i;
i=100;
i*=100;
printf("%Ld",i);
return 0;
}
I get the following:
-727379968
instead of the expected 1
I am using gcc 3.3.1
the same code works nicely on linux machine with gcc 3.3.1
is any other information necessary?

dj



--
Unsubscribe info:  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.7s: gdb crash on exit

[Rolf Campbell]

I just realized that gdb (at least on my machine) always crashes if you 
attach to any process, then try to quit.

Rolf Campbell wrote:

I've noticed a problem with the snapshot (it's not limited to the 
snapshot, it was there in 1.5.6 as well).  The problem may have been in 
1.5.5 as well, but it was definitely less pronounced there.

If I run "make -j6" or something, on our large corporate build 
environment, then sometimes, one or more make instances will end up 
freezing.  (They spin in place, using up as much cpu as they can, 
forever).  ^C stops them.  I can't find any easy way to produce this 
with smaller examples (and it doesn't even always happen on my big 
builds).  It seems to happen about 75% of the time with my builds, so I 
don't have any real problem reproducing it.

I tried attaching to the process with gdb, but I didn't really know what 
to do after I was attached:
-
(gdb) attach 524
Attaching to process 524
[Switching to thread 524.0x38c]
(gdb) bt
#0  0x77f75a59 in ntdll!DbgUiConnectToDbg () from 
/c/WINDOWS/System32/ntdll.dll
#1  0x77f5f31f in ntdll!KiUserCallbackDispatcher ()
   from /c/WINDOWS/System32/ntdll.dll
#2  0x0005 in ?? ()
#3  0x0004 in ?? ()
#4  0x0001 in ?? ()
#5  0x003fffd0 in ?? ()
#6  0x85005480 in ?? ()
#7  0x in ?? ()
#8  0x77fa88f0 in wcstombs () from /c/WINDOWS/System32/ntdll.dll
(gdb) p/x *(int *)$ebp
$1 = 0x0
(gdb) info thread
* 4 thread 524.0x38c  0x77f75a59 in ntdll!DbgUiConnectToDbg ()
   from /c/WINDOWS/System32/ntdll.dll
  3 thread 524.0x270  0x7ffe0304 in ?? ()
  2 thread 524.0xc14  0x7ffe0304 in ?? ()
  1 thread 524.0xff0  0x00419015 in ?? ()
(gdb) quit
The program is running.  Quit anyway (and detach it)? (y or n) ye

Segmentation fault (core dumped)

[EMAIL PROTECTED] ~
$

Also, gdb crashed as you can see.  Gdb seems to crash if i attach to a 
process, then try to quit.  I ran gdb under gdb, but it didn't produce a 
usefull traceback:
(gdb) q

Program received signal SIGSEGV, Segmentation fault.
0x0042454c in ?? ()
(gdb) bt
#0  0x0042454c in ?? ()
#1  0x0ec0 in ?? ()
I understand that I haven't provided much usefull info, I am willing to 
try other things apon suggestion.



Cygwin Win95/NT Configuration Diagnostics
Current System Time: Tue Jan 20 12:04:02 2004
Windows XP Professional 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
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)
SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `rcampbell'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
CLIENTNAME = `Console'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `DESK-RCAMPBELL'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
COSMIC = `t'
CVS_RSH = `/bin/ssh'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\rcampbell'
HOSTNAME = `desk-rcampbell'
INFOPATH = 
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LOGONSERVER = `\\EXCHANGE'
MANPATH = 
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
NUMBER_OF_PROCESSORS = `2'
OLDPWD = `/c/base2/node'
OS = `Windows_NT'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0209'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
SESSIONNAME = `Console'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp'
TERM = `xterm'
TMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp'
TROPIC_UNIQUE_ID = `150'
USERDNSDOMAIN = `TROPICNETWORKS.COM'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINDOWS'
WINDOWID = `168127776'
_ = `/usr/bin/cygcheck'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\

1.5.7s: make freezes (sometimes)

[Rolf Campbell]

I've noticed a problem with the snapshot (it's not limited to the 
snapshot, it was there in 1.5.6 as well).  The problem may have been in 
1.5.5 as well, but it was definitely less pronounced there.

If I run "make -j6" or something, on our large corporate build 
environment, then sometimes, one or more make instances will end up 
freezing.  (They spin in place, using up as much cpu as they can, 
forever).  ^C stops them.  I can't find any easy way to produce this 
with smaller examples (and it doesn't even always happen on my big 
builds).  It seems to happen about 75% of the time with my builds, so I 
don't have any real problem reproducing it.

I tried attaching to the process with gdb, but I didn't really know what 
to do after I was attached:
-
(gdb) attach 524
Attaching to process 524
[Switching to thread 524.0x38c]
(gdb) bt
#0  0x77f75a59 in ntdll!DbgUiConnectToDbg () from 
/c/WINDOWS/System32/ntdll.dll
#1  0x77f5f31f in ntdll!KiUserCallbackDispatcher ()
   from /c/WINDOWS/System32/ntdll.dll
#2  0x0005 in ?? ()
#3  0x0004 in ?? ()
#4  0x0001 in ?? ()
#5  0x003fffd0 in ?? ()
#6  0x85005480 in ?? ()
#7  0x in ?? ()
#8  0x77fa88f0 in wcstombs () from /c/WINDOWS/System32/ntdll.dll
(gdb) p/x *(int *)$ebp
$1 = 0x0
(gdb) info thread
* 4 thread 524.0x38c  0x77f75a59 in ntdll!DbgUiConnectToDbg ()
   from /c/WINDOWS/System32/ntdll.dll
  3 thread 524.0x270  0x7ffe0304 in ?? ()
  2 thread 524.0xc14  0x7ffe0304 in ?? ()
  1 thread 524.0xff0  0x00419015 in ?? ()
(gdb) quit
The program is running.  Quit anyway (and detach it)? (y or n) ye

Segmentation fault (core dumped)

[EMAIL PROTECTED] ~
$

Also, gdb crashed as you can see.  Gdb seems to crash if i attach to a 
process, then try to quit.  I ran gdb under gdb, but it didn't produce a 
usefull traceback:
(gdb) q

Program received signal SIGSEGV, Segmentation fault.
0x0042454c in ?? ()
(gdb) bt
#0  0x0042454c in ?? ()
#1  0x0ec0 in ?? ()
I understand that I haven't provided much usefull info, I am willing to 
try other things apon suggestion.

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Tue Jan 20 12:04:02 2004

Windows XP Professional 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

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)

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

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

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
CLIENTNAME = `Console'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `DESK-RCAMPBELL'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
COSMIC = `t'
CVS_RSH = `/bin/ssh'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\rcampbell'
HOSTNAME = `desk-rcampbell'
INFOPATH = 
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LOGONSERVER = `\\EXCHANGE'
MANPATH = 
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
NUMBER_OF_PROCESSORS = `2'
OLDPWD = `/c/base2/node'
OS = `Windows_NT'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0209'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
SESSIONNAME = `Console'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp'
TERM = `xterm'
TMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp'
TROPIC_UNIQUE_ID = `150'
USERDNSDOMAIN = `TROPICNETWORKS.COM'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINDOWS'
WINDOWID = `168127776'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `C:'
 

Re: regtool freezes on XP (Was: Re: [ANNOUNCEMENT] Updated: cygwin-1.5.6-1)

[Rolf Campbell]

Christopher Faylor wrote:

On Mon, Jan 19, 2004 at 01:48:52PM -0800, David Rothenberger wrote:

I think the problem is bash, not regtool.  The following script also 
displays the problem:

---begin script---
#!/bin/sh
ls
---end script---
Does the latest snapshot fix this problem?
Yes, yes it does.

--
Unsubscribe info:  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: Compile dclock fails

[Rolf Campbell]

Yup, it does fail.  This is because it's written in improper C.

[EMAIL PROTECTED] wrote:

[EMAIL PROTECTED] ~
$ gzip -dc dclock_2.1.2.orig.tar.gz |tar xvf -
dclock/
dclock/Dclock.c
dclock/Dclock.h
dclock/DclockP.h
dclock/Imakefile
dclock/README
dclock/TODO
dclock/dclock.c
dclock/Dclock.ad
dclock/sounds/
dclock/sounds/bell.wav
dclock/sounds/digital.wav
dclock/dclock.1
dclock/Makefile.orig
[EMAIL PROTECTED] ~
$ cd dclock
[EMAIL PROTECTED] ~/dclock
$ xmkmf
imake -DUseInstalled -I/usr/X11R6/lib/X11/config
[EMAIL PROTECTED] ~/dclock
$ make depend
makedepend  --   -I/usr/X11R6/include-D__i386__ -DWIN32_LEAN_AND_MEAN 
-DX_LOCALE  -D_X86_ -D__CYGWIN__ -D_XOPEN_SOURCE   
-D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE 
-DFUNCPROTO=15 -DNARROWPROTO -DUSE_MAKEDEPEND -- Dclock.c dclock.c

[EMAIL PROTECTED] ~/dclock
$ make
gcc -O2 -fno-strength-reduce -Wall -Wpointer-arith -I/usr/X11R6/include 
-D__i386__ -DWIN32_LEAN_AND_MEAN -DX_LOCALE -D_X86_ -D__CYGWIN__ 
-D_XOPEN_SOURCE  -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE   
-D_SVID_SOURCE -D_GNU_SOURCE  -DFUNCPROTO=15 
-DNARROWPROTO   -c -o dclock.o dclock.c
dclock.c: In function `Usage':
dclock.c:91: warning: implicit declaration of function `exit'
dclock.c: At top level:
dclock.c:105: warning: return type defaults to `int'
dclock.c: In function `main':
dclock.c:110: warning: suggest parentheses around assignment used as truth 
value
dclock.c:127: warning: control reaches end of non-void function
rm -f dclock.exe
gcc -o dclock.exe -O2 -fno-strength-reduce -Wall -Wpointer-arith 
-L/usr/X11R6/lib   Dclock.o dclock.o -lXt -lSM -lICE -lXext -lX11   -lm 
-Wl,--enable-auto-import
dclock.o(.text+0xb40):dclock.c: multiple definition of `_main'
Dclock.o(.text+0xb40):dclock.c: first defined here
Dclock.o(.text+0xbd3):dclock.c: undefined reference to 
`_dclockWidgetClass'
dclock.o(.text+0xbd3):dclock.c: undefined reference to 
`_dclockWidgetClass'
collect2: ld returned 1 exit status
make: *** [dclock.exe] Error 1

[EMAIL PROTECTED] ~/dclock
$


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

regtool freezes on XP (Was: Re: [ANNOUNCEMENT] Updated: cygwin-1.5.6-1)

[Rolf Campbell]

When I run this script *not* from another cygwin program (Windows Run 
menu as "bash -c scriptname.sh", or from W32 GNU Emacs)
---begin script
#!/bin/sh
echo -n Getting location...
regtool get '\'
---end script
I get the expected output:
Getting location...Unknown key prefix.  Valid prefixes are:
	root
	HKCR
	HKEY_CLASSES_ROOT
	config
	HKCC
	HKEY_CURRENT_CONFIG
	user
	HKCU
	HKEY_CURRENT_USER
	machine
	HKLM
	HKEY_LOCAL_MACHINE
	users
	HKU
	HKEY_USERS

BUT, it then freezes (that is sh.exe freezes, after regtool finishes) 
(Ctrl+C does nothing, kill -9 does nothing, /bin/kill -f works).  This 
worked correctly in 1.5.5, and it still works on my Win2000Pro box, but 
not on my XP box.  It does not matter what arguments you pass to regtool 
(I just tried it with none and it still froze).  This is a hyperthreaded 
machine (if that makes any difference).  I can try it with HT turned off 
if you want.

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Mon Jan 19 16:21:34 2004

Windows XP Professional 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

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)

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

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

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
CLIENTNAME = `Console'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `DESK-RCAMPBELL'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
COSMIC = `t'
CVS_RSH = `/bin/ssh'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\rcampbell'
HOSTNAME = `desk-rcampbell'
INFOPATH = 
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LOGONSERVER = `\\EXCHANGE'
MANPATH = 
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
NUMBER_OF_PROCESSORS = `2'
OLDPWD = `/home/rcampbell'
OS = `Windows_NT'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0209'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
SESSIONNAME = `Console'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp'
TERM = `xterm'
TMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp'
USERDNSDOMAIN = `TROPICNETWORKS.COM'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINDOWS'
WINDOWID = `168128144'
_ = `/usr/bin/cygcheck'

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

a:  fd   N/AN/A
c:  hd  NTFS   39260Mb  45% CP CS UN PA FC 
d:  cd   N/AN/A

C:\cygwin  /  system  binmode
C: /c system  binmode
C:\cygwin/bin  /usr/bin   system  binmode
C:\cygwin/lib  /usr/lib   system  binmode
.  /cygdrive  system  binmode,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:\cygwi

Re: auto_ptr gcc version 3.3.1 (cygming special) problem

[Rolf Campbell]

#1)  This is not a cygwin issue, so it's off-topic here.
#2)  This is not even really a gcc issue, it's a C++ issue.
#3)  The problem is that you are trying to use static_cast too much.  It 
should only be used for built-in types (int, float, various pointers).

The older gcc seemed to allow incorrect use of static_cast, the new one 
requires you to use it right.

Just remove the static casts, and away we are:

int main(int argc, char *argv[])
{
  A a(1);
  auto_ptr b = auto_ptr(a.getB());
  A a2(2);
  auto_ptr b2 = auto_ptr(a2.getB());
  cin.get();
  return 0;
}
Or even:

int main(int argc, char *argv[])
{
  A a(1);
  auto_ptr b(a.getB());
  A a2(2);
  auto_ptr b2(a2.getB());
  cin.get();
  return 0;
}


Marcelo Rezende Módolo wrote:
Hi,
I am not shure that this is a error , but it is very strange...
//autoPtr.cpp
#include 
#include 
using namespace std;
class B  {
public:
   B(int cid) : cid_(cid) { cout << "B(" << cid_ << ")\n"; }
   ~B() { cout << "~B(" << cid_ << ")\n"; }
private:
   int cid_;  };
class A  {
public:
   A(int cid) : cid_(cid) { cout << "A(" << cid_ << ")\n"; }
   ~A() { cout << "~A(" << cid_ << ")\n"; } B* getB() { return new 
B(cid_); }
private:
   int cid_;  };

int main(int argc, char *argv[])
{
   A a(1);
   auto_ptr b = static_cast< auto_ptr >(a.getB());
   A a2(2);
   auto_ptr b2 = static_cast< auto_ptr >(a2.getB());
   cin.get();
 return 0;
}
If I compile this file with gcc version 3.2.3 (mingw special 20030504-1) 
no errors ocur (g++ -o autoPtr autoPtr.cpp).
But if I try to compile using gcc version 3.3.1 (cygming special), with 
the same command line (g++ -o autoPtr autoPtr.cpp),
this errors ocur:
autoPtr.cpp: In function `int main(int, char**)':
autoPtr.cpp:26: error: invalid static_cast from type `B*' to type `
  std::auto_ptr'
autoPtr.cpp:29: error: invalid static_cast from type `B*' to type `
  std::auto_ptr'

what is the problem??

thanks,
marcelo




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

List responces (Was: Re: Third-party products that include Cygwin)

[Rolf Campbell]

Larry Hall wrote:
At 05:24 PM 12/13/2003, Hannu E K Nevalainen you wrote:
PLEASE NOTE:
** on a mailing list; please keep replies on that particular list **
I'm a little confused by the intent of your "note" above.  If this is 
directed at me, I replied to your message the way I always reply, with
"reply all".  That goes to the list.  It also goes to you directly, since
you don't set your reply-to header.  If you prefer to get just one copy 
of any reply (i.e. the one that goes to the list), set your reply-to
header to point to the list.  My email client will obey your stated 
preference automatically.  Of course, if you were directing this comment
at someone else, then you can ignore the above.
You have made an assumption that everyone accesses this list the same 
way you do.  For those of us that use the nntp gateway, we cannot set 
our reply-to field to be the list.



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

Re: cygwin too slow

[Rolf Campbell]

http://cygwin.com/problems.html

koorapati, koundinya wrote:
Hey Cygwin users,
 After using UNIX desktops for nearly seven years now, I'm forced to use
a windows desktop. Since I knew a thing like cygwin existed, I installed the
complete set of packages and I was thrilled. But simple commands like ls
take this time
$ time ls -l
total 23
drwxr-xr-x1 kkoorapa mkgroup-0 Nov 11 17:50 Mail
-rw-r--r--1 kkoorapa mkgroup-   39 Nov 10 17:42 t.c
-rwxr-xr-x1 kkoorapa mkgroup-11224 Nov 10 17:40 t.exe
-rwxr-xr-x1 kkoorapa mkgroup-11224 Nov 10 17:43 tt.exe
real0m18.115s
user0m0.020s
sys 0m0.010s
Likewise any utility I try to use like vi, emacs etc just take really long.
I'm not sure how  I could debug this. I did try to use strace etc, but got
no clues. Searching the archives also did not help me. BTW, I use Win 2000
Pro on a DELL Box with 512MB RAM and at this time, top shows this:
 18:18:11 up  7:57,  0 users,  load average: 0.00, 0.00, 0.00
7 processes: 6 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:   0.2% user,   1.2% system,   0.0% nice,  98.6% idle
Mem:58K total,   210788K used,   311440K free,0K buffers
Swap:   753248K total,   276720K used,   476528K free,0K cached
Thanks for any help !

Koundinya




--
Unsubscribe info:  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.1: can't open files beginning with "..."

[Rolf Campbell]

To make things even more interesting, it thinks that anything starting 
with '...' is a character device?

/home/rcampbell> ll ..
crw-rw-rw-1 rcampbel   0,   0 Oct 24 14:28 ..
/home/rcampbell> touch ...
touch: creating `...': No such device or address
Chris Moore wrote:
I have a file on my PC called "...foo.txt".

cygwin has a problem with this file:

  $ ls -a
  .  ..  ...foo.txt  cygcheck.out
  $ ls -al > /dev/null
  ls: ...foo.txt: No such file or directory
  $ 

cygwin also has a problem making similarly named files:

  $ touch ...foo2.txt
  touch: creating `...foo2.txt': No such file or directory
Windows Explorer also doesn't like to make files whose names begin
with 3 dots, but Windows itself is fine with them.  The following
Perl one-liner makes the file if you run it in the (native Windows)
ActiveState Perl:
  open(FP, ">...foo3.txt") or die "$!";

But the cygwin perl complains:

  "No such file or directory at 3dots.pl line 1.".

I can also create these '3 dot' files in a native Win32 Emacs, but
not in the cygwin Emacs.  Even a Windows 'DOS prompt' (cmd.exe) is
able to make it:
  C:\>echo foo > ...foo3.txt
  C:\>
I'm not sure how to tell you what version of cygwin this is, but the
'DLL version' is 1.5.5 if that's what you need to know.
I've attached the output of "cygcheck -s -v -r".

Chris.





Cygwin Win95/NT Configuration Diagnostics
Current System Time: Fri Oct 24 13:56:27 2003
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
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1006(Chris) GID: 513(None)
513(None)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1006(Chris) GID: 513(None)
513(None)544(Administrators)  
545(Users)

SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS
HOME = `c:\Chris'
MAKE_MODE = `unix'
PWD = `/cygdrive/c/Chris/cygwin'
USER = `Chris'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\Chris\Application Data'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `CHRISLAP'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
CVS_RSH = `/bin/ssh'
DJGPP = `c:\djgpp\djgpp.env'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\Chris'
HOSTNAME = `CHRISLAP'
LOGONSERVER = `\\CHRISLAP'
MANPATH = `:/usr/X11R6/man:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/cygdrive/c/Chris'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 4, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0204'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
PS1 = `\W $ '
SESSIONNAME = `Console'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `c:\DOCUME~1\Chris\LOCALS~1\Temp'
TERM = `cygwin'
TMP = `c:\DOCUME~1\Chris\LOCALS~1\Temp'
TZ = `GMT-2'
USERDOMAIN = `CHRISLAP'
USERNAME = `Chris'
USERPROFILE = `C:\Documents and Settings\Chris'
WINDIR = `C:\WINDOWS'
_ = `/usr/bin/cygcheck'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
  (default) = `C:'
  unix = `/'
  fbinary = 0x
  fsilent = 0x
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
HKEY_LOCAL_MACHINE\SOFTWARE\Cy

Re: Program too big to fit in memory - Previous hints didn't work

[Rolf Campbell]

E G wrote:
I run the max_memory program included in Chapter 3 of the users manual I 
think, and it reports 1560 kB. So I'm discarding real memory problems.
Well, that's the problem, you only have 1.5 Megs of ram free.



--
Unsubscribe info:  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: Possible bug in text/binary mode handling in cygwin1.dll version 1.5

[Rolf Campbell]

Vladimir Vysotsky wrote:
Hi,

I'm using the following sequence of actions to reproduce this problem:


C:\test>bash
bash-2.05b$ echo "Test" >/c/test/test1.txt
bash-2.05b$ echo "Test" >c:/test/test2.txt
bash-2.05b$ ls -l
total 2
-rw-r--r--1 vvysotsk mkpasswd6 Oct 10 19:49 test1.txt
-rw-r--r--1 vvysotsk mkpasswd6 Oct 10 19:49 test2.txt
bash-2.05b$

Since drive C: is mounted in text mode (mount -f -s -t "c:" /c), both 
test1.txt and test2.txt are 6 bytes long ('T', 'e', 's', 't', 0x0D, 
0x0A). This is with cygwin1.dll version 1.3.2.

However, when I install cygwin1.dll version 1.5.x, test2.txt is only
5 bytes long, ending with just 0x0A:
C: is not mounted in text mode.  /c is mounted in text mode.  C: isn't 
mounted at all.

If you set CYGWIN=textmode then that would mean that windows-style paths 
would be treated as text-mounts.



--
Unsubscribe info:  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: Recent snapshots and bash/stopping processes

[Rolf Campbell]

Igor Pechtchanski wrote:

On Mon, 6 Oct 2003, Rolf Campbell wrote:


Corinna Vinschen wrote:

On Mon, Oct 06, 2003 at 10:00:53AM -0400, Rolf Campbell wrote:


Open one window (rxvt):
$ sleep 1000
Open a seperate window (rxvt):
$ ps
PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
   1716   11716   1716  con 11643 18:57:52 /usr/bin/rxvt
   163617161636   17240 11643 18:57:52 /usr/bin/bash
   1832   11832   1832  con 11643 18:59:13 /usr/bin/rxvt
   2072   12072   2072  con 11643 09:35:13 /usr/bin/rxvt
   232020722320   22602 11643 09:35:16 /usr/bin/bash
   2360   12360   2360  con 11643 09:50:50 /usr/bin/rxvt
   184423601844   24043 11643 09:50:53 /usr/bin/bash
   244823202448   24602 11643 09:51:07 /usr/bin/sleep
   228418442284   24523 11643 09:51:10 /usr/bin/ps
$ kill -STOP 2448
$
Look back at first window:
$ sleep 1000
[1]+  Stopped sleep 1000
$
This has only started happending with recent cygwin versions, I'm
running Oct2 right now.
Erm... and what's wrong with this?  It's the same as on Linux.
Well, if this is design intent, then that's fine.  But, on older
cygwins, it used to just stop the process (the parent of the stopped
process (bash) did nothing).  It seems a little awkward to me at least,
if I stop/start a process, then I end up with both bash & that process
running at the same time, in the same console.
Rolf,

The last sentence doesn't make sense.  If you're complaining about the
notification, put a "set +b" (or "set +o notify") in your .bashrc.
Igor
I'm not complaining about the notification, I'm complaining about the 
fact that bash resumes it's interactivity when one of it's children 
processes receive a stop signal (that it didn't generate).

/home/rcampbell> set +b
/home/rcampbell> sleep 100
[1]+  Stopped sleep 100



--
Unsubscribe info:  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: Recent snapshots and bash/stopping processes

[Rolf Campbell]

Corinna Vinschen wrote:
On Mon, Oct 06, 2003 at 10:00:53AM -0400, Rolf Campbell wrote:

Open one window (rxvt):
$ sleep 1000
Open a seperate window (rxvt):
$ ps
 PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
1716   11716   1716  con 11643 18:57:52 /usr/bin/rxvt
163617161636   17240 11643 18:57:52 /usr/bin/bash
1832   11832   1832  con 11643 18:59:13 /usr/bin/rxvt
2072   12072   2072  con 11643 09:35:13 /usr/bin/rxvt
232020722320   22602 11643 09:35:16 /usr/bin/bash
2360   12360   2360  con 11643 09:50:50 /usr/bin/rxvt
184423601844   24043 11643 09:50:53 /usr/bin/bash
244823202448   24602 11643 09:51:07 /usr/bin/sleep
228418442284   24523 11643 09:51:10 /usr/bin/ps
$ kill -STOP 2448
$
Look back at first window:
$ sleep 1000
[1]+  Stopped sleep 1000
$
This has only started happending with recent cygwin versions, I'm 
running Oct2 right now.
Erm... and what's wrong with this?  It's the same as on Linux.
Well, if this is design intent, then that's fine.  But, on older 
cygwins, it used to just stop the process (the parent of the stopped 
process (bash) did nothing).  It seems a little awkward to me at least, 
if I stop/start a process, then I end up with both bash & that process 
running at the same time, in the same console.



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

Recent snapshots and bash/stopping processes

[Rolf Campbell]

Open one window (rxvt):
$ sleep 1000
Open a seperate window (rxvt):
$ ps
  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
 1716   11716   1716  con 11643 18:57:52 /usr/bin/rxvt
 163617161636   17240 11643 18:57:52 /usr/bin/bash
 1832   11832   1832  con 11643 18:59:13 /usr/bin/rxvt
 2072   12072   2072  con 11643 09:35:13 /usr/bin/rxvt
 232020722320   22602 11643 09:35:16 /usr/bin/bash
 2360   12360   2360  con 11643 09:50:50 /usr/bin/rxvt
 184423601844   24043 11643 09:50:53 /usr/bin/bash
 244823202448   24602 11643 09:51:07 /usr/bin/sleep
 228418442284   24523 11643 09:51:10 /usr/bin/ps
$ kill -STOP 2448
$
Look back at first window:
$ sleep 1000
[1]+  Stopped sleep 1000
$
This has only started happending with recent cygwin versions, I'm 
running Oct2 right now.


Cygwin Win95/NT Configuration Diagnostics
Current System Time: Mon Oct 06 09:57:25 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
c:\cygwin\bin
C:\WINNT\SYSTEM32
C:\WINNT
C:\WINNT\SYSTEM32\WBEM
C:\PERFORCE
C:\cygwin\bin
C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
C:\Perforce
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Program Files\SSH

Output from c:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)

Output from c:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)

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

CYGWIN = `binmode'
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `rcampbell'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PCRCAMPBELL2'
COMSPEC = `C:\WINNT\system32\cmd.exe'
COSMIC = `c:/node.beta1/COSMIC'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\'
LOGONSERVER = `\\PCRCAMPBELL2'
MANPATH = `:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/c/base2/node/comp'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSE_ROOT = `C:\OSE\OSE4.4.1\'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw;.pys'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0806'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\]$PWD\[\]>\[\] '
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `C:\Temp'
TERM = `xterm'
TROPIC_UNIQUE_ID = `150'
USERDNSDOMAIN = `tropicnetworks.com'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINNT'
WINDOWID = `168046576'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `C:'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start 
Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:/cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/bin
  (default) = `c:\cygwin\bin'
  flags = 0x004a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/bin/cygcheck.exe
  (default) = `c:\cygwin\bin\cygcheck.exe'
  flags = 0x001a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/bin/strace.exe
  (default) = `c:\cygwin\bin\strace.exe'
  flags = 0x001a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:/cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:/cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS   19069Mb  76% CP CS UN PA FC Campbell
d:  cd  CDFS   0Mb -2147483548%CS  Audio CD

C: 

Re: Out of Memory

[Rolf Campbell]

read the faq

黄显刚 wrote:
> Dear All,
> 
> My System Environment as below:
> 
> Windows 2000 Professional
> Cygwin version 2.78.2.9
> Phyical Memory: 256M
> Virtual Memory: 1.5G
> Perl v5.6.1 built for cygwin-multi
> 
> When I run my perl program which needs about 1G memory, the following
> happened: 
> 
> "Out of memory during request for 1016 bytes, total sbrk() is 261015552
> bytes!".
> 
> So my program was forced to die.
> 
> You are most appreciated! All the best!
> 
> Best regards,
> 
> Huang Xiangang
> Bioinformatics Department
> Beijing Genomics Institute
> Beijing Airport Industrial Zone B 6
> Phone: (010) 8048 2174 (H), 8048 1511 (O)
> Mobile: 1391 096 5821
> 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/

Google (Was: Re: __CYGWIN__ ++ (RE: getuid() and root))

[Rolf Campbell]

Hannu E K Nevalainen (garbage mail) wrote:
Searching the archives, w google (I'm VERY negative vs "htdig" right now)
+"CYGWIN" +"-mno-cygwin" site:cygwin.com inurl:ml
gives 1450 hits...
I'm out of ideas on how to refine this - to find anything that matches
__NOCYGWIN__ or similar.
At times I'm VERY frustrated with search engines (e.g. google) for their
incapability to do what the help files indicate. Adding a "+" before a word,
as I have done above, is meant to REQUIRE that word to be in the items
shown. IMO this DOESN'T happen.
It does, but google doesn't handle '-'s very well.  I thinks of it as a 
word seperator.



--
Unsubscribe info:  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: feature requests for setup

[Rolf Campbell]

peter garrone wrote:
- Have setup check with the mirror to see if the setup program itself 
   has been upgraded. For people who dont read announcements.
It does.  After it's been 'officially' released.



--
Unsubscribe info:  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: Invocation of executable file on a machine which doesn't have Cygwin installed

[Rolf Campbell]

Not unless you install at least the cygwin base package on the 2nd 
machine.  Or compile with -mno-cygwin.

Alex Vinokur wrote:
Windows 2000

---
1. Machine#1. Cygwin is installed.
foo.cpp is some c++ program
$ g++ foo.cpp -o foo.exe
---
2. Machine#2. Cygwin is not installed.
Will foo.exe work on Machine#2?
   =
   Alex Vinokur
 mailto:[EMAIL PROTECTED]
 http://mathforum.org/library/view/10978.html
   =






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

Re: ^C not getting to sub, sub, sub, sub processes

[Rolf Campbell]

Christopher Faylor wrote:
I have a reproducable (at least on my machine) of some ^C handling issues.

#!/bin/python
import sys, os, select
if(int(sys.argv[1]) > 0):
  os.system(sys.argv[0] + " %d" % (int(sys.argv[1])-1))
else:
  select.select([], [], [], 10)
Try running this as "./deep.py 0", and then, when it's waiting, hit ^C, 
it will terminate fine.  Now try it as "./deep.py 1", and then hit ^C. 
Nothing happens.  I see this when I try to cancel my build, but ^C 
doesn't work when the process tree is too deep.


Interesting.  This is an *ancient* bug.  I think it even predates my
involvment in cygwin.  It was a bug in the system() call.  It should be
fixed in the latest snapshot, available now.
Thanks for the test case.
No problem, thank you for the quick fix (works great now).  BTW, I have 
some machines that are still running 1.3.17, and I could not reproduce 
this ^C issue on them.  I don't really care, but I thought I would 
mention it.



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

^C not getting to sub, sub, sub, sub processes (was: Re: 1.5.4s assertion "hsig_inited" failed)

[Rolf Campbell]

Christopher Faylor wrote:

On Fri, Aug 15, 2003 at 09:10:12PM -0400, Rolf Campbell wrote:

Christopher Faylor wrote:

On Mon, Sep 08, 2003 at 04:44:58PM -0400, Rolf Campbell wrote:

I started a large build, then hit ^Z.  Then "fg", and this is what 
happened:
A large build shouldn't even recognize the ^Z if you are running this from
the console.  Your TERM=xterm below.  Are you running this under X?
I am using RXVT.  Does RXVT set TERM=xterm?  That's my only guess, I 
don't set that variable myself.


Huh.  I guess so.  It does so for me, as well.

This problem sounded familiar so I did a little archive diving.  It was
reported before and I investigated it before.  I remember thinking that
this would be hard to fix owing to a race condition with signals in tty
code.  I can make this fail in various interesting ways even outside of
the pty/tty code, though.  So, I'm investigating why now.
cgf

I have a reproducable (at least on my machine) of some ^C handling issues.

#!/bin/python
import sys, os, select
if(int(sys.argv[1]) > 0):
os.system(sys.argv[0] + " %d" % (int(sys.argv[1])-1))
else:
select.select([], [], [], 10)
Try running this as "./deep.py 0", and then, when it's waiting, hit ^C, 
it will terminate fine.  Now try it as "./deep.py 1", and then hit ^C. 
Nothing happens.  I see this when I try to cancel my build, but ^C 
doesn't work when the process tree is too deep.

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Fri Sep 19 14:29:26 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\WINNT\SYSTEM32
C:\WINNT
C:\WINNT\SYSTEM32\WBEM
C:\PERFORCE
C:\cygwin\bin
C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
C:\Perforce
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Program Files\SSH

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)

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

CYGWIN = `binmode'
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/home/rcampbell'
USER = `rcampbell'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PCRCAMPBELL2'
COMSPEC = `C:\WINNT\system32\cmd.exe'
COSMIC = `c:/node.beta1/COSMIC'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\'
LOGONSERVER = `\\EXCHANGE'
MANPATH = `:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/usr/bin'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSE_ROOT = `C:\OSE\OSE4.4.1\'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw;.pys'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0806'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\]$PWD\[\]>\[\] '
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `C:\Temp'
TERM = `xterm'
TROPIC_UNIQUE_ID = `150'
USERDNSDOMAIN = `tropicnetworks.com'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINNT'
WINDOWID = `168046576'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `C:'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start 
Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:/cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:/cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:/cygwin/lib'
  flags = 0x000

Re: objdump : inaccurate demangling for foo(char* const)

[Rolf Campbell]

foo(char* const) is no different from foo(char*), from the perspective 
of linking/overloading.

Did you mean foo(char const *)?

Alex Vinokur wrote:
==
Windows 2000 Professional
CYGWIN_NT-5.0 1.5.4(0.94/3/2)
GNU gcc version 3.2 20020927 (prerelease)
GNU objdump 2.14.90 20030901
==
It seems that objdump inaccurately demangles foo(char* const).
  Low-level symbol name of foo(char* const) is valid : __Z3fooPc
  But user-level symbol name obtained after demangling is inaccurate : foo(char*).


== C++ code : BEGIN ==
// File t.cpp
void foo3 (char*) {}

== C++ code : END 



== Compilation : BEGIN ==

$ g++ -c t.cpp

== Compilation : END 



== objdump : BEGIN ==

$ objdump -d t.o

t.o: file format pe-i386

Disassembly of section .text:

 <__Z3fooPc>:// OK
   0: 55push   %ebp
   1: 89 e5 mov%esp,%ebp
   3: 5dpop%ebp
   4: c3ret
   5: 90nop
   6: 90nop
   7: 90nop
   8: 90nop
   9: 90nop
   a: 90nop
   b: 90nop
   c: 90nop
   d: 90nop
   e: 90nop
   f: 90nop




$ objdump -Cd t.o

t.o: file format pe-i386

Disassembly of section .text:

 :// Must be foo(char* const)
   0: 55push   %ebp
   1: 89 e5 mov%esp,%ebp
   3: 5dpop%ebp
   4: c3ret
   5: 90nop
   6: 90nop
   7: 90nop
   8: 90nop
   9: 90nop
   a: 90nop
   b: 90nop
   c: 90nop
   d: 90nop
   e: 90nop
   f: 90nop
== objdump : END 

--
   =
   Alex Vinokur
 mailto:[EMAIL PROTECTED]
 http://mathforum.org/library/view/10978.html
   =






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

Re: getopt: ugly linker messages

[Rolf Campbell]

Bryan Higgins wrote:
Christopher Faylor wrote:


You can use unistd.h if you want.  If you knew this already why were you
asking the question?


From the gnu getopt(3) man page (mysteriously missing in cygwin):

   #include 

   int getopt(int argc, char * const argv[],
  const char *optstring);
   extern char *optarg;
   extern int optind, opterr, optopt;
If one does this with the latest cygwin, ugly linker messages result.

I believe you are interpreting the man page incorrectly.  You should 
only include  and not the 4 lines below that.  The rest of the 
lines are only to show you the 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: Setup installation order?

[Rolf Campbell]

Igor Pechtchanski wrote:

On Tue, 16 Sep 2003, Rick Rankin wrote:
I ran into a situation I hadn't seen before a few days ago when I used
setup to update my Cygwin installation from 1.5.3 to 1.5.4. What
happened was that there were several packages, in addition to
cygwin-1.5.4, that had updates available. Setup downloaded the updates,
then uninstalled the old packages, including cygwin-1.5.3. When it went
to install the updates, cygwin-1.5.4 was *not* the first package that
got installed, so any postinstallion scripts failed with a dialog box
from the O/S saying that "Windows cannot find cygwin1.dll in " until after cygwin itself was updated. After setup installed the
cygwin package, the rest of the postinstall scripts ran fine.
Is the cygwin package given any special consideration during the install
process (e.g., last to be uninstalled, first to be (re)installed), or is
this something that's expected to be handled by the dependency list?
I've been perusing the setup sources, but I haven't quite figured out
the dependency processing, yet. So far, I haven't found anything related
via Google searches, either.
--Rick


The setup program simply performs a topological sort of the package
dependence graph, and then traverses the packages in that order.  Of
course, since the graph is cyclic, topological order is not unique.  In
any case, the postinstall scripts should run after *all* the packages are
unpacked, so you shouldn't be missing cygwin1.dll on postinstall.
However, preremove scripts are run just before the corresponding package
is removed (in alphabetical order, IIRC).  This presents a problem, but
noone so far has considered it a large enough problem to invest the effort
in a fix.  It's likely that you saw this particular problem in your
upgrade.  .
Igor
Wouldn't it make sence to call each preremove script before any packages 
are actually removed?



--
Unsubscribe info:  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: bash-2.05b-15 still broken

[Rolf Campbell]

Christopher Faylor wrote:
I can't reproduce that... BUT having a plain prompt like this in rxvt:

$

and hitting CTRL-C makes bash bail out. (i.e. the rxvt window closes)

And I cannot reproduce either problem.


I can.  It's odd.  I wonder why I didn't notice this in my own testing
since I did this hundreds of times last week.  It appears to be a cygwin
problem.
This is a pretty serious bug.  I'll see if I can narrow down what's
causing it.  So far it resists simple efforts to just run gdb on
rxvt.
cgf

If it helps, it worked in the Sept12 snap, but not the 13th.



--
Unsubscribe info:  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.5s + ^C or ^Z = bad

[Rolf Campbell]

Rolf Campbell wrote:

Hannu E K Nevalainen (garbage mail) wrote:

From: Alexander Osipenko


 I can't reproduce that... BUT having a plain prompt like this in rxvt:

 $

and hitting CTRL-C makes bash bail out. (i.e. the rxvt window closes)

And I cannot reproduce either problem.

After upgrading to the latest snapshot, ^C or ^Z from while running bash 
or less (probably other programs too) causes that console to hang for 
about 10 seconds, then dissapear.

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Tue Sep 16 15:49:50 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\WINNT\SYSTEM32
C:\WINNT
C:\WINNT\SYSTEM32\WBEM
C:\PERFORCE
C:\cygwin\bin
C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
C:\Perforce
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Program Files\SSH

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)

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

CYGWIN = `binmode'
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `rcampbell'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PCRCAMPBELL2'
COMSPEC = `C:\WINNT\system32\cmd.exe'
COSMIC = `c:/node.beta1/COSMIC'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\'
LOGONSERVER = `\\PCRCAMPBELL2'
MANPATH = `:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/home/rcampbell'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSE_ROOT = `C:\OSE\OSE4.4.1\'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw;.pys'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0806'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\]$PWD\[\]>\[\] '
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `C:\Temp'
TERM = `xterm'
TROPIC_UNIQUE_ID = `150'
USERDNSDOMAIN = `tropicnetworks.com'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINNT'
WINDOWID = `168046576'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `C:'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start 
Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:/cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:/cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:/cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS   19069Mb  75% CP CS UN PA FC Campbell
d:  cd  CDFS   0Mb -2147483548%CS  Audio CD

C: /cuserbinmode
.  /cygdrive userbinmode,cygdrive
C:/cygwin  / system  binmode
C:/cygwin/bin  /usr/bin  system  binmode
C:/cygwin/lib  /usr/lib  system  binmode
C:\cygwin\usr\X11R6\lib\X11\fonts  /usr/X11R6/lib/X11/fonts  system  binmode
.  /cygdrive system  binmode,cygdrive

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\b

Re: bash-2.05b-15 still broken

[Rolf Campbell]

Hannu E K Nevalainen (garbage mail) wrote:
From: Alexander Osipenko


Just as described in article
http://www.cygwin.com/ml/cygwin/2003-09/msg00825.html
PS1='\[\e]0;\w\a\e[32;1m\]$ \[\e[0m\]'

current directory contais 2 scripts: `pkgcheck.pl'  and `pkgwget.sh`
Starting a command:
$ ./pk

and pressing TAB 3 times (one for completion ./pkg and other two
for the list of completions), string
pkgcheck.pl  pkgwget.sh
$ ./pkgpkg
appears and after ^H (or ^U)

$ ./p

these 3 characters remains unerasable
 I can't reproduce that... BUT having a plain prompt like this in rxvt:

 $

and hitting CTRL-C makes bash bail out. (i.e. the rxvt window closes)

And I cannot reproduce either problem.



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

Re: [ANNOUNCEMENT] Updated Bash package available for download

[Rolf Campbell]

Thanks Ronald, seems to run just as good as -13 now.

Ronald Landheer-Cieslak wrote:
New News:
=
Version 2.05b-15 of the Bash package is now available for download.
This is a bugfix release relative to 2.05b-14, and fixes the bug reported in
http://www.cygwin.com/ml/cygwin/2003-09/msg00822.html
The applied patch is temporary and will be replaced by a more permanent (less
kludgy) solution later.
To update your installation:
===
Run the Setup utility from http://cygwin.com/setup.exe and pick up the 
proper packages.

Problem reports:
===
Please send reports of any problems related to these packages to 
[EMAIL PROTECTED] and *do not* mail me personally. I moniter the list on a 
regular basis.

Old News:

Bash is an sh-compatible shell that incorporates useful features from the Korn
shell (ksh) and C shell (csh).
It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools
standard.
It offers functional improvements over sh for both programming and interactive
use. In addition, most sh scripts can be run by Bash without modification.
Port Notes:
==
- version 2.05b-15 -
Applied a temporary patch to fix the problem reported in
http://www.cygwin.com/ml/cygwin/2003-09/msg00822.html
- version 2.05b-14 -
Additional canonical patches 5 through 7 applied
- version 2.05b-13 and earlier -
Earlier versions were maintained by Corinna Vinschen. The history may be found
in the cygwin-announce archives.
- End forwarded 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/

Re: [ANNOUNCEMENT] Updated: cygwin-1.5.4-1

[Rolf Campbell]

uname -a

Editor of PoliSource wrote:
1.5.4-1 is obviously later than what I got, but how would I find the 
version number of my current version? It doesn't seem to be in the file 
name.

_
Use custom emotions -- try MSN Messenger 6.0! 
http://www.msnmessenger-download.com/tracking/reach_emoticon




--
Unsubscribe info:  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: Available for testing: gcc-3.3.1-1 and gcc-mingw-20030911-1

[Rolf Campbell]

Danny Smith wrote:
On Sat, Sep 13, 2003 at 12:43:38PM -0400, Rolf Campbell wrote:
Christopher Faylor wrote:
On Sat, Sep 13, 2003 at 12:20:39PM -0400, Rolf Campbell wrote:
Is this new gcc supposed to be ABI compatible with 3.2.x?  Because I 
can't link in libraries compiled with an older version of cygwin g++.

/c/temp/cppunit-1.8.0/src/cppunit/TestSucessListener.cpp: undefined 
reference to `___gxx_personality_v0'
/c/temp/cppunit-1.8.0/src/cppunit/../../include/cppunit/TestListener.h:33: 
undefined reference to `__Unwind_Resume'
gcc 3.2-3 used Dwarf2 exceptions, which worked most of the time. (In fact,
I don't recall any bug reports at all on cygwin list).  But it didn't work
with w32api callbacks, nor with some combinations of compiler switches
(notably -mcpu=i586 or -mno-accumulate-outgoing-args and
-fomit-frame-pointer).
cygwin gcc-3.3.1 uses setjmp-longjmp exception mechanism,
mingw does too and has done since gcc-3.2.1.
The two undefined references are Dwarf2 specific.  The corresponding
SjLj symbols are __gxx_personality_sj0 and  __Unwind_SjLj_Resume.
Danny
Ok, are there command-line switches to change the exception mechanism 
used?  I would like to be able to use cygwin gcc 3.2 to build libraries 
that work with cygwin gcc 3.3.



--
Unsubscribe info:  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: Available for testing: gcc-3.3.1-1 and gcc-mingw-20030911-1

[Rolf Campbell]

Charles Wilson wrote:

Rolf Campbell wrote:

Is this new gcc supposed to be ABI compatible with 3.2.x?  Because I 
can't link in libraries compiled with an older version of cygwin g++.

/c/temp/cppunit-1.8.0/src/cppunit/TestSucessListener.cpp: undefined 
reference to `___gxx_personality_v0'
/c/temp/cppunit-1.8.0/src/cppunit/../../include/cppunit/TestListener.h:33: 
undefined reference to `__Unwind_Resume'

I get about 200 of those.

Oh, and my cygcheck took 3.4seconds.
What happens if you use 'fabi-version=1' ?  '-fabi-version=0' ?

Also, what does the following command show:

g++ -E -dM - < /dev/null | awk '/GXX_ABI/ {print $3}'

gcc-3.2-3 gives "102"

Chuck
Ok, it's not really an ABI change.  It's just that the newer g++ doesn't 
provide/require the "___gxx_personality_v0" or "__Unwind_Resume" 
symbols.  So, any library produced with 3.2-3 will not link into an app 
compiled with 3.3.1-1.



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

Re: [ANNOUNCEMENT] Updated: cygwin-1.5.4-1

[Rolf Campbell]

Which mirror did you use?  Try rcn.net

Hannu E K Nevalainen (garbage mail) wrote:

Subject: [ANNOUNCEMENT] Updated: cygwin-1.5.4-1


 I get cygwin1.dll "1.3.22-dontuse-21" by running setup.exe and cycling to
"All @ Install" in package selection, i.e. postinstall stuff barfs out.
Hrm... setup.exe doesn't seem to have 1.5.x listed anywhere, or am I blind?

/Hannu E K Nevalainen, B.Sc. EE - 59°16.37'N, 17°12.60'E

Yet another sad "9/11" story
 -> http://cnn.com/2003/WORLD/europe/09/11/sweden.stabbing/index.html
--END OF 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/

/bin/kill -f complains but succeeds for non-cygwin apps

[Rolf Campbell]

/c/base2/node> notepad &
[1] 1888
/c/base2/node> ps
  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
 1936   11936   1936  con 11643 13:35:48 /usr/bin/rxvt
 139219361392   20400 11643 13:35:48 /usr/bin/bash
 188813921888   18880 11643 14:03:38 
/c/WINNT/SYSTEM32/notepad
 177613921776   18200 11643 14:03:42 /usr/bin/ps
/c/base2/node> /bin/kill -f 1888
couldn't kill pid 1888, 5


Cygwin Win95/NT Configuration Diagnostics
Current System Time: Sat Sep 13 14:05:36 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\WINNT\SYSTEM32
C:\WINNT
C:\WINNT\SYSTEM32\WBEM
C:\PERFORCE
C:\cygwin\bin
C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
C:\Perforce
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Program Files\SSH

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)

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

CYGWIN = `binmode'
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/c/base2/node'
USER = `rcampbell'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PCRCAMPBELL2'
COMSPEC = `C:\WINNT\system32\cmd.exe'
COSMIC = `c:/node.beta1/COSMIC'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\'
LOGONSERVER = `\\PCRCAMPBELL2'
MANPATH = `:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/c/base2/node/comp'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSE_ROOT = `C:\OSE\OSE4.4.1\'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw;.pys'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0806'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\]$PWD\[\]>\[\] '
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `C:\Temp'
TERM = `xterm'
TROPIC_UNIQUE_ID = `150'
USERDNSDOMAIN = `tropicnetworks.com'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINNT'
WINDOWID = `168046576'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `C:'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start 
Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:/cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:/cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:/cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS   19069Mb  74% CP CS UN PA FC Campbell
d:  cd  CDFS   0Mb -2147483548%CS  Audio CD

C: /cuserbinmode
.  /cygdrive userbinmode,cygdrive
C:/cygwin  / system  binmode
C:/cygwin/bin  /usr/bin  system  binmode
C:/cygwin/lib  /usr/lib  system  binmode
C:\cygwin\usr\X11R6\lib\X11\fonts  /usr/X11R6/lib/X11/fonts  system  binmode
.  /cygdrive system  binmode,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

Re: Available for testing: gcc-3.3.1-1 and gcc-mingw-20030911-1

[Rolf Campbell]

Christopher Faylor wrote:

On Sat, Sep 13, 2003 at 12:20:39PM -0400, Rolf Campbell wrote:

Is this new gcc supposed to be ABI compatible with 3.2.x?  Because I 
can't link in libraries compiled with an older version of cygwin g++.

/c/temp/cppunit-1.8.0/src/cppunit/TestSucessListener.cpp: undefined 
reference to `___gxx_personality_v0'
/c/temp/cppunit-1.8.0/src/cppunit/../../include/cppunit/TestListener.h:33: 
undefined reference to `__Unwind_Resume'
Apparently not.

cgf
Ok, let me rephrase:  Do you consider this a problem worth fixing?



--
Unsubscribe info:  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: Available for testing: gcc-3.3.1-1 and gcc-mingw-20030911-1

[Rolf Campbell]

Is this new gcc supposed to be ABI compatible with 3.2.x?  Because I 
can't link in libraries compiled with an older version of cygwin g++.

/c/temp/cppunit-1.8.0/src/cppunit/TestSucessListener.cpp: undefined 
reference to `___gxx_personality_v0'
/c/temp/cppunit-1.8.0/src/cppunit/../../include/cppunit/TestListener.h:33: 
undefined reference to `__Unwind_Resume'

I get about 200 of those.

Oh, and my cygcheck took 3.4seconds.

Christopher Faylor wrote:

I've made test versions of gcc 3.3.1 (and the accompanying gcc-mingw
package) available via setup.  This version is the 3.3.1 release plus
the usual cygwin + mingw patches -- most of which come from Danny Smith.
The set of custom patches necessary for cygwin and mingw is shrinking
all of the time.  gcc 3.4 should be much better in this regard.
Anyway, it seems to work fine.  Usual caveats apply.

Problems go to the cygwin mailing list as always.

But you know that.

cgf


Cygwin Win95/NT Configuration Diagnostics
Current System Time: Sat Sep 13 12:16:27 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\WINNT\SYSTEM32
C:\WINNT
C:\WINNT\SYSTEM32\WBEM
C:\PERFORCE
C:\cygwin\bin
C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
C:\Perforce
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Program Files\SSH

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)

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

CYGWIN = `binmode'
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `rcampbell'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PCRCAMPBELL2'
COMSPEC = `C:\WINNT\system32\cmd.exe'
COSMIC = `c:/node.beta1/COSMIC'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\'
LOGONSERVER = `\\PCRCAMPBELL2'
MANPATH = `:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/home/rcampbell'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSE_ROOT = `C:\OSE\OSE4.4.1\'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw;.pys'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0806'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\]$PWD\[\]>\[\] '
SHLVL = `3'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `C:\Temp'
TERM = `xterm'
TROPIC_UNIQUE_ID = `150'
USERDNSDOMAIN = `tropicnetworks.com'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINNT'
WINDOWID = `168046576'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `C:'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start 
Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:/cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:/cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:/cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS   19069Mb  74% CP CS UN PA FC Campbell
d:  cd  CDFS   0Mb -2147483548%CS  Audio CD

C: /cuserbinmode
.  /cygdrive userbinmode,cygdrive
C:/cygwin  / system  binmode
C:/cygwin/bin  /usr/bin  system  binmode
C:/cygwin/lib  /usr/lib  system  binmode
C:\cygwin\usr\X11R6\lib\X11\fonts  /usr/X11R6/lib/X11/fonts  sy

Re: bash-2.05b-14 broken!

[Rolf Campbell]

Yeah, this bash has the same problems that -12 did, and more.

PS1='\[\]$PWD\[\]>\[\] '
There are some literal escape chars in that...
I get a colored prompt like this:
/home/rcampbell>
if I type t, then I see a list of possible completions, and:

/home/rcampbell> t t
^^
These 2 characters have magically appeared, and are not erasable.
Sam Steingold wrote:

PS1="\[\e[33;1m\]\t\[\e[m\] \[\e[36;1m\]\w [\#]\\$\[\e[m\] "
there are two spaces after "$", not one as it should be
(and as it was with bash-2.05b-13 and on all the other unixes).
another manifestation of the same bug: when the command line is folded,
it folds one extra line.
apparently, the prompt output code prints one extra space which it does
not account for internally.


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

Re: ANNOUNCEMENT for bash?

[Rolf Campbell]

Oops, s/th/sh/

Rolf Campbell wrote:
I noticed there's a new version of bash out -14, but no announcement?

-Rolf





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

ANNOUNCEMENT for bath?

[Rolf Campbell]

I noticed there's a new version of bash out -14, but no announcement?

-Rolf



--
Unsubscribe info:  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: win2k "resource" exhaustion problem - no Cygwin programs will run

[Rolf Campbell]

Why not try uninstalling the firewall/virus scanner, restart your 
computer, and try this again.

james pentland wrote:
i ran my script again after killing all my other user
processes - firewall, virus watcher, pgp and other.
the problem persists.

it does, however, appear to be memory related.
as the script runs, physical memory usage climbs
slowly to 225248k (out of 261424k), at which point the
script dies.
i show some system statistics below.



From: Luc Hermitte <[EMAIL PROTECTED]> 
To: [EMAIL PROTECTED] 
Date: Fri, 12 Sep 2003 00:57:14 +0200 
Subject: Re: win2k "resource" exhaustion problem - no
Cygwin programs will run 
References:
<[EMAIL PROTECTED]> 


Hello,


It looks like a problem several people are
experimenting.

Lately, someone exposed a link between this problem
and Agnitum Outpost

(a firewall) that seems to forget to free some
resources. This sounds

plausible, from my point of view, as I also have
Outpost and I'm

experimenting this problem.


[BTW, Rampage was evoked as a possible workaround,
but it had no

positive effect on my system.]


HTH,
Luc Hermitte






[[--]] TRANSCRIPT OF CONSOLE SESSION - NO OTHER USER
PROCESSES RUNNING
[EMAIL PROTECTED] /ntd/new
$ ./yawfu-sh
COUNT=1
COUNT=2
[...]
COUNT=2536
COUNT=2537
COUNT=2538
COUNT=2539
COUNT=2540
./yawfu-sh.txt: line 7: /usr/bin/cat: Permission
denied
COUNT=2541
./yawfu-sh.txt: line 7: /usr/bin/cat: Permission
denied
COUNT=2542
./yawfu-sh.txt: line 7: /usr/bin/cat: Permission
denied
COUNT=2543
./yawfu-sh.txt: fork: Permission denied
./yawfu-sh.txt: line 7: /usr/bin/cat: Permission
denied
[EMAIL PROTECTED] /ntd/new
$ 

[EMAIL PROTECTED] /ntd/new
$ ./yawfu-sh.txt
bash: ./yawfu-sh.txt: /bin/bash: bad interpreter:
Permission denied
[EMAIL PROTECTED] /ntd/new
$ ps
bash: /usr/bin/ps: Permission denied




[[--]] WINDOWS TASK MANAGER STATISTICS AT TERMINATION
OF SCRIPT
Physical Memory (K)
Total  261424
Available  73912
System Cache  107848
Processes: 24
Mem Usage: 225248K / 633156K
Handles:  3155
Threads  214
Processes  24
Kernel Memory (K)
Total  55052
Paged  27352
Nonpaged  27700
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.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/

Re: 1.5.4s assertion "hsig_inited" failed

[Rolf Campbell]

Christopher Faylor wrote:
On Mon, Sep 08, 2003 at 04:44:58PM -0400, Rolf Campbell wrote:
I started a large build, then hit ^Z.  Then "fg", and this is what happened:
A large build shouldn't even recognize the ^Z if you are running this from
the console.  Your TERM=xterm below.  Are you running this under X?
I am using RXVT.  Does RXVT set TERM=xterm?  That's my only guess, I 
don't set that variable myself.



--
Unsubscribe info:  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.4s assertion "hsig_inited" failed

[Rolf Campbell]

I started a large build, then hit ^Z.  Then "fg", and this is what happened:

begin
make[2]: Leaving directory `/c/base2/node/comp/DiagNodeScheduler'
make[2]: Entering directory `/c/base2/node/comp/equipConf'
[1]+  Stopped nice -20 make -rsw -C pload/SCC target
/c/base2/node> fg
nice -20 make -rsw -C pload/SCC target
assertion "hsig_inited" failed: file 
"/netrel/src/cygwin-snapshot-20030908-1/winsup/cygwin/sigproc.cc", line 204
Signal 6
make[1]: *** [__build__equipConf] Interrupt
make: *** [bsp-CC8260] Interrupt

---end-

After the "Signal 6" line, some process (I killed it before finding out 
exactly which process) was using 100% of the CPU until I hit ^C.

I have been unable to reproduce the problem.  But, in my attempts, I 
found a couple of other issuses.  I should mention here that this build 
system spends most of it's time running non-cygwin programs.

If I hit ^Z while a non-cygwin process is running, there seems to be 
about a 50% chance of everything working as expected:
  - after non-cygwin process finishes, return to shell, can rusume make 
with fg.

But, the other 50% of the time, the cygwin processes stop, but the shell 
does not present a prompt again.  (running kill -CONT  
 rusumes the build).

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Mon Sep 08 16:19:58 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\WINNT\SYSTEM32
C:\WINNT
C:\WINNT\SYSTEM32\WBEM
C:\PERFORCE
C:\cygwin\bin
C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
C:\Perforce
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Program Files\SSH

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)

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

CYGWIN = `binmode'
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `rcampbell'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PCRCAMPBELL2'
COMSPEC = `C:\WINNT\system32\cmd.exe'
COSMIC = `c:/node.beta1/COSMIC'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\'
LOGONSERVER = `\\OTTDC2'
MANPATH = `:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/home/rcampbell'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSE_ROOT = `C:\OSE\OSE4.4.1\'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw;.pys'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0806'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\]$PWD\[\]>\[\] '
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `C:\Temp'
TERM = `xterm'
TROPIC_UNIQUE_ID = `150'
USERDNSDOMAIN = `tropicnetworks.com'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINNT'
WINDOWID = `168046576'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `C:'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start 
Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:/cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:/cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:/cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS   19069Mb  78% CP CS UN PA FC Campbell
d:  cd  CDFS   0Mb -2147483548%CS  Audio CD

C: /cuserbinmode
.   

Re: Problem with COM1 port from with GDB 5.3 under Cygwin 1.5.3-1

[Rolf Campbell]

Creighton MacDonnell wrote:

Can other people use the COM1 port OK with the new Cygwin?
I did notice a difference.  Specifically, opening "COM1" no longer opens 
 the com port.  You must use "/dev/com1" now.



--
Unsubscribe info:  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: rxvt sets DISPLAY without X11

[Rolf Campbell]

Andrew DeFaria wrote:
Hans Werner Strube wrote:

If rxvt is used from the login shell outside X11, without XWin running 
and /tmp/.X11-unix/ empty, it nevertheless sets DISPLAY to ':0'. This 
even happens if rxvt is started directly from a Windows shortcut:
C:\cygwin\bin\rxvt.exe -e /bin/bash --login Does this have a special 
meaning or is it a bug?


rxvt does not set DISPLAY for me. You must be setting it somewhere else 
(Windows environment variables perhaps?)

It does set it for me.  And it is RXVT that sets it.

RXVT:
/home/rcampbell> set | grep DISPLAY
DISPLAY=:0
/home/rcampbell>
WINNT console:
/home/rcampbell> set | grep DISPLAY
/home/rcampbell>


--
Unsubscribe info:  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: two versions

[Rolf Campbell]

Eduardo Osorio Armenta wrote:

Hi,

i want to test cygwin 1.5.X

but not break my set cygwin 1.3.22

so i wonder if installing cygwin 1.5.X in
another path e.g. c:\cygwin_1.5
and configuring all the PATH to my shell (cygwin.bat)
to only include c:\cygwin_1.5\bin (and all related)
would not interfere with my cygwin 1.3.22
it's that posible?
Not really.

or the registry stuff will prevent this!
Bingo.

You can do it if you switch mount tables/paths when you switch between 
versions.



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

Re: [ANNOUNCEMENT] Updated: bash-2.05b-13

[Rolf Campbell]

Thanks for fixing this problem.  I still notice one other problem (this 
has not been recently introduced).

RXVT:
If the prompt string is longer than the width, then bash will not wrap 
it correctly.  It seems to introduce EOL at (w+8) and 2w (where w is the 
 real terminal width).  I've tested this at real term widths of 30, 40, 
and 80 (EOLs are introduced at (38, 60), (48, 80) and (88, 160) repectively.

WinNT console:
The EOLs are in different positions, but they are still there.  They are 
at (w+19) and (2w-2).

To demonstrate, run:
PS1='003-007-011-015-019-023-027-031-035-039-043-047-051-055-059-063-067-071-075-079-083-087-091-095-099-103-107-111-115-119-123-127-131-135-139-143-147-151-155-159-163-167-171-175-179-183-187-191-195-199-203-207-211-215-219-223-227-231-235-239-243-247-251-255-259-263-267-271-275-279-283-287-291-295-299-303-307-311-315-319-323-327-331-335-339-343-347-351-355-359-363-367-371-375-379-383-387-391-395-399-403-407-411-415-419-423-427-431-435-439-443-447-451-455-459-463-467-471-475-479-483-487-491-495-499>'
(ignoring all line breaks introduced by mail software).  The value of 
each number is the number of characters from the start, up to and 
including the end of that number.

With a terminal width of 30, I see this:

003-007-011-015-019-023-027-031-035-03
1-035-03
9-043-047-051-055-059-
063-067-071-075-079-083-087-091-095-09
9-103-107-111-115-119-123-127-131-135-
139-143-147-151-155-159-163-167-171-17
5-179-183-187-191-195-199-203-207-211-
215-219-223-227-231-235-239>
The end of line#2 & line#3 is not correct.

Corinna Vinschen wrote:

I've updated the version of bash to 2.05b-13.

This release removes the wide-character capability which has been
introduced in -11 and which resulted in redrawing problems.
This bash requires Cygwin 1.5.3 ff.

To update your installation, click on the "Install Cygwin now" link on  
the http://sources.redhat.com/cygwin web page.  This downloads setup.exe
to your system.  The, run setup and answer all of the questions.

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.
Note that we do not allow downloads from sources.redhat.com (aka
cygwin.com) due to bandwidth limitations.  This means that you will need
to find a mirror which has this update.  You might have to wait as much
as 24 hours to find a mirror with the updated version of cygwin on it.
Be patient.
If you have questions or comments, please send them to the Cygwin  
mailing list at: [EMAIL PROTECTED] .  I would appreciate it if you would
use this mailing list rather than emailing me directly.

If you want to make a point or ask a question, the Cygwin mailing list   
is the appropriate place.  This includes ideas and comments about the
setup utility or Cygwin in general.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

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

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

Please read *all* of the information on unsubscribing that is available
starting at this URL.
I implore you to READ this information before sending email about how
you "tried everything" to unsubscribe.  In 100% of the cases where 
people were unable to unsubscribe, the problem was that they hadn't  
actually read and comprehended the unsubscribe instructions.

If you need to unsubscribe from cygwin-announce or any other mailing
list, reading the instructions at the above URL is guaranteed to
provide you with the info that you need.

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Wed Sep 03 13:49:18 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\WINNT\SYSTEM32
C:\WINNT
C:\WINNT\SYSTEM32\WBEM
C:\PERFORCE
C:\cygwin\bin
C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
C:\Perforce
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Program Files\SSH

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)

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

CYGWIN = `binmode'
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `rcampbell'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PCRCA

Re: [ANNOUNCEMENT] Updated: bash-2.05b-12

[Rolf Campbell]

Igor Pechtchanski wrote:
On Tue, 2 Sep 2003, Corinna Vinschen wrote:


I've updated the version of bash to 2.05b-12.

This bash now uses the new capabilities and therefore requires
Cygwin 1.5.3 ff.
The package now adheres to the filesystem hirarchy standard (FHS).


Corinna,

There is a minor problem with the latest bash: it duplicates the last
literal character of the prompt or the last character of the entered
command upon redraw.  To duplicate, "export PS1='\[\033[32m\033[0m\]$'"
(you should see the prompt as '$$'), then enter any word and press ^L to
redraw (you should see the last character of that word duplicated, and
the prompt becomes '$').  If the last character of the prompt is not a
literal character (e.g., if you append '\[\]' to PS1) the last prompt
character duplication problem goes away, but the last character of the
command is still duplicated upon redraw.
I'm hoping it's something simple.  If you don't know right away what the
problem is, or can't replicate it, let me know and I'll provide more
debugging info.  I'm using cygwin-1.5.3-1 and bash-2.05b-12.
Igor
I noticed this in the transition from -10 to -11.  I posted my 
observation http://www.cygwin.com/ml/cygwin/2003-08/msg00109.html

-Rolf



--
Unsubscribe info:  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 crash with latest inetutils and cygwin 1.5

[Rolf Campbell]

Christopher Faylor wrote:

On Sat, Aug 30, 2003 at 10:57:47PM -0400, Rolf Campbell wrote:

Christopher Faylor wrote:

On Sat, Aug 30, 2003 at 10:22:28PM -0400, Rolf Campbell wrote:

I was able to reproduce using the latest snapshot on Win2000 SP4.
That's odd. I thought you couldn't run any programs at all.

It's nice that some of us can remain so objective and professional.  You 
really make my minimal yet positive contributions feel worthwhile.


I'm sorry.  I got you confused with Ronald Landheer-Cieslak:

http://sources.redhat.com/ml/cygwin/2003-08/msg01443.html

It wasn't intended as an insult, in any event.  It was a genuine expression
of puzzlement.  Now I'm no longer puzzled about that aspect of the problem
at least.
cgf
Appology accepted



--
Unsubscribe info:  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 crash with latest inetutils and cygwin 1.5

[Rolf Campbell]

Christopher Faylor wrote:
On Sat, Aug 30, 2003 at 10:22:28PM -0400, Rolf Campbell wrote:
I was able to reproduce using the latest snapshot on Win2000 SP4.
That's odd. I thought you couldn't run any programs at all.
cgf
It's nice that some of us can remain so objective and professional.  You 
really make my minimal yet positive contributions feel worthwhile.

-Rolf



--
Unsubscribe info:  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 crash with latest inetutils and cygwin 1.5

[Rolf Campbell]

I was able to reproduce using the latest snapshot on Win2000 SP4.

Christopher Faylor wrote:
On Sat, Aug 30, 2003 at 05:36:51PM -0400, Pierre A. Humblet wrote:

The following is 100% reproducible with ftp from inetutils
1.3.2-23 and -24, and any Cygwin 1.5.X.
I have not tried other combinations.
Note the mispelling of the site in the initial command. 

~: ftp mysite.verzion.net
ftp: connect to address 208.38.59.182: Connection refused
Trying 208.38.59.183...
ftp: connect to address 208.38.59.183: Connection refused
Trying 208.38.61.25...
ftp: connect to address 208.38.61.25: Connection refused
Trying 199.72.44.116...
ftp: connect to address 199.72.44.116: Connection refused
Trying 208.38.59.181...
ftp: connect: Connection refused
ftp> open mysite.verizon.net
Segmentation fault (core dumped)
Here is the stack

#1  0x61043c54 in dlfree (mem=0x980828) at
../../../../src/winsup/cygwin/malloc.cc:3781
#2  0x6104c20a in free_hostent_ptr(hostent*&) ([EMAIL PROTECTED]) at
../../../../src/winsup/cygwin/net.cc:972
#3  0x6104c57b in cygwin_gethostbyname (name=0x413ef5 "mysite.verizon.net")
at ../../../../src/winsup/cygwin/net.cc:1048
CYGWIN_ME-4.90 hpn5170x 1.5.3(0.90/3/2) 2003-08-30 14:50 i686 unknown
unknown Cygwin


Can't duplicate this with Windows XP or Windows 98.  Does the latest
snapshot also behave the same way?  That's what I'm using.
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: how can i use my own func in stdio.a?,such as printf

[Rolf Campbell]

Gdb has an api that can be used for this sort of stuff.  Insight uses it.

zhao mindong wrote:
Because i want to use gdb as a part of my IDE(windows platform),but 
think it too slow if i use pipe to communicate with gdb,so i want to 
using my stdio func to get the gdb's output...just an idea


From: Rolf Campbell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: how can i use my own func in stdio.a?,such as printf
Date: Tue, 26 Aug 2003 22:39:51 -0400
why would you want to use your own printf?

zhao mindong wrote:

   i want to use my own printf,but i must use the other function 
declared in stdio.h,there is always an error"previous defined",how 
can i solve the problem.
  another question,how can i build the cygwin1.dll?any reference or 
document here? thanks.

_
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/
_
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail




--
Unsubscribe info:  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: parallel make

[Rolf Campbell]

Christopher Faylor wrote:
On Wed, Aug 27, 2003 at 09:03:55PM -0400, Rolf Campbell wrote:

Christopher Faylor wrote:

On Wed, Aug 27, 2003 at 08:15:19PM -0400, Rolf Campbell wrote:

make -j does work in cygwin, to an extent.  If you try to use too many
processes, cygwin seems to flip out.  -j20 does seem to work fine
though (it only starts acting strang around -j100).
More likely it "flips out" around -j62 or so.
Is this a real responce?  Or is this some more dry humour?


It's a real response.
So, you are saying that there are known scalability issuse with cygwin? 
 Like with the number of processes?

Does cygwin only allow 64 processes at once?

-Rolf



--
Unsubscribe info:  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: parallel make

[Rolf Campbell]

Christopher Faylor wrote:

On Wed, Aug 27, 2003 at 08:15:19PM -0400, Rolf Campbell wrote:

make -j does work in cygwin, to an extent.  If you try to use too many 
processes, cygwin seems to flip out.  -j20 does seem to work fine though 
(it only starts acting strang around -j100).
More likely it "flips out" around -j62 or so.

cgf
Is this a real responce?  Or is this some more dry humour?

-Rolf



--
Unsubscribe info:  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: parallel make

[Rolf Campbell]

make -j does work in cygwin, to an extent.  If you try to use too many 
processes, cygwin seems to flip out.  -j20 does seem to work fine though 
(it only starts acting strang around -j100).

On my large build system, we have a slow disk, and I find that when the 
disk cache is empty, -j4 speeds it up about 40%.  When the build system 
is cached, -j slows things down by a few percent.  This is dealing with 
1 processor.  Of course, if you have multiple processors, the speed 
should scale linearly (with 4 cpu's, -j4 is about 70% faster).

Rich Elberger wrote:

Hi folks,
Currently our build environment uses parallel make (-j jobs option) on all
our unixes using gnu tools.  We use an older version of gnu tools on our
windows boxes.  The older make on the windows box does not do parallel
make (or at least correctly).  I want to upgrade to the latest cygwin to
see if parallel make works, but this will require significant changes to
our build engine, so I would like to confirm a few things if possible.
1. Does the -j jobs option work well on windows. (part b: does it work
with the MSVC (6/7) compiler (which probably doesn't make a difference
anyway)?
2. Has anyone done this in a very large project, and if so, do you have
any performance gain stats (which, I acknowledge, is tied to
processor-intensive makes and how many processors the machine has).
I realize that dos does not allow for threading so I don't know if this is
a cmd.exe-related issue or not (since cmd.exe is the parent shell, I
don't know if this affects the behavior).
thanks in advance --




--
Unsubscribe info:  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.3s: /dev/clipboard does not work for non-cygwin programs

[Rolf Campbell]

chris wrote:

Rolf Campbell wrote:

$ ipconfig > /dev/clipboard
$ ipconfig | cat > /dev/clipboard
The first command does *nothing* to the content of the clipboard.
The 2nd command does what I expected the first command to do.


Unfortunatly under windows it is up to the application to handle things 
like | , > , etc. therefore I don't think this could ever be supported.
That's not true at all.  Windows console programs inherit there io 
handles just like unix programs.



--
Unsubscribe info:  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.3s: /dev/clipboard does not work for non-cygwin programs

[Rolf Campbell]

Christopher Faylor wrote:

On Wed, Aug 27, 2003 at 11:51:20AM -0400, Rolf Campbell wrote:

$ ipconfig > /dev/clipboard
$ ipconfig | cat > /dev/clipboard
The first command does *nothing* to the content of the clipboard.  The
2nd command does what I expected the first command to do.


And is this a regression?  
Not really.  I only recently started using /dev/clipboard.

> I would be astonished if a non-cygwin program could understand a 
cygwin-specific device like /dev/clipboard.

I was running this all from bash.  Isn't it bash that sets up the it's 
i/o handles before forking the sub-process?  So, theoretically, couldn't 
cygwin do something special if it is launching a non-cygwin app with 
cygwin-specific devices as it's i/o handles?

-Rolf



--
Unsubscribe info:  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.3s: /dev/clipboard does not work for non-cygwin programs

[Rolf Campbell]

$ ipconfig > /dev/clipboard
$ ipconfig | cat > /dev/clipboard
The first command does *nothing* to the content of the clipboard.
The 2nd command does what I expected the first command to do.


Cygwin Win95/NT Configuration Diagnostics
Current System Time: Wed Aug 27 11:47:50 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\WINNT\SYSTEM32
C:\WINNT
C:\WINNT\SYSTEM32\WBEM
C:\PERFORCE
C:\cygwin\bin
C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
C:\Perforce
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Program Files\SSH

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)

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

CYGWIN = `binmode'
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `rcampbell'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PCRCAMPBELL2'
COMSPEC = `C:\WINNT\system32\cmd.exe'
COSMIC = `c:/node.beta1/COSMIC'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\'
LOGONSERVER = `\\PCRCAMPBELL2'
MANPATH = `:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/c/base2/node'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSE_ROOT = `C:\OSE\OSE4.4.1\'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw;.pys'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0806'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\]$PWD\[\]>\[\] '
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `C:\Temp'
TERM = `xterm'
TROPIC_UNIQUE_ID = `150'
USERDNSDOMAIN = `tropicnetworks.com'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINNT'
WINDOWID = `168046576'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `C:'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start 
Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:/cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:/cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:/cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS   19069Mb  82% CP CS UN PA FC Campbell
d:  cd   N/AN/A

C: /cuserbinmode
.  /cygdrive userbinmode,cygdrive
C:/cygwin  / system  binmode
C:/cygwin/bin  /usr/bin  system  binmode
C:/cygwin/lib  /usr/lib  system  binmode
C:\cygwin\usr\X11R6\lib\X11\fonts  /usr/X11R6/lib/X11/fonts  system  binmode
.  /cygdrive system  binmode,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 - os=4.0 img=1.0 sys=4.0
  "cygbz2-1.dll" v0.0 ts=2003/8/9 2:35
   54k 2002/01/27 C:\cygwin\bin\cygbz21.0.

Re: how can i use my own func in stdio.a?,such as printf

[Rolf Campbell]

why would you want to use your own printf?

zhao mindong wrote:
   i want to use my own printf,but i must use the other function 
declared in stdio.h,there is always an error"previous defined",how can i 
solve the problem.
  another question,how can i build the cygwin1.dll?any reference or 
document here? thanks.

_
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail




--
Unsubscribe info:  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: Bare minimum packages to DL for install?

[Rolf Campbell]

I believe the min is the default.

[EMAIL PROTECTED] wrote:
Hi --

I have an unreliable internet connection, so I can't use the internet
install with setup.exe.  I am trying to install cygwin after first
downloading the packages, but there are way too many for me to download
all of them.
I have two questions:

What is the bare minimum of packages I need to install to get bash working?

Is it possible to install and add packages afterwards, like if I want to
try out stuff later?
Thanks for the help.



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

1.5.3s and rxvt and keypad = double keys

[Rolf Campbell]

When running the new snapshot, I noticed something strange.  When using 
rxvt, the keypad keys "+" and "-" produce "++" and "--" respectively. 
There was a post about this before, but then it only seemed to happen 
with CYGWIN set to "tty".  Mine is set to "binmode".

A normal Win2000 console operates normally.  And the normal "+" key 
works normally in both console programs.

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Fri Aug 22 18:48:07 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\WINNT\SYSTEM32
C:\WINNT
C:\WINNT\SYSTEM32\WBEM
C:\PERFORCE
C:\cygwin\bin
C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
C:\Perforce
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Program Files\SSH

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell) GID: 10513(Domain Users)
544(Administrators)   545(Users)
10513(Domain Users)

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

CYGWIN = `binmode'
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `rcampbell'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PCRCAMPBELL2'
COMSPEC = `C:\WINNT\system32\cmd.exe'
COSMIC = `c:/node.beta1/COSMIC'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\'
LOGONSERVER = `\\OTTDC2'
MANPATH = `:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/home/rcampbell'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSE_ROOT = `C:\OSE\OSE4.4.1\'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw;.pys'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0806'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\]$PWD\[\]>\[\] '
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `C:\Temp'
TERM = `xterm'
TROPIC_UNIQUE_ID = `150'
USERDNSDOMAIN = `tropicnetworks.com'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINNT'
WINDOWID = `168046576'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `C:'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start 
Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:/cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:/cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:/cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS   19069Mb  76% CP CS UN PA FC Campbell
d:  cd  CDFS   0Mb -2147483548%CS  Audio CD

C: /cuserbinmode
.  /cygdrive userbinmode,cygdrive
C:/cygwin  / system  binmode
C:/cygwin/bin  /usr/bin  system  binmode
C:/cygwin/lib  /usr/lib  system  binmode
C:\cygwin\usr\X11R6\lib\X11\fonts  /usr/X11R6/lib/X11/fonts  system  binmode
.  /cygdrive system  binmode,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.e

Re: 1.3.22-1 on XP: malloc returns overlapping buffers

[Rolf Campbell]

Unable to reproduce using Win2000 SP4 (cygwin 1.5.2).

roconnor wrote:
I am finding that under some circumstances a buffer returned by malloc
will overlap with a buffer returned by a previous call to malloc that
has not been freed.  I was able to reduce it to the following test
case.  Running under cygwin 1.3.22-1 on Windows XP Professional
Version 2002 SP1 it reports an overlap of 4824 bytes on two different
machines, as well as on a third machine running Windows 2000 5.00.2195
SP4.  On Windows NT 4.0.1381, it finds no overlap.
Am I doing something wrong or is there a bug in malloc or XP?  More
details below.


#include 
#include 
int
main (int argc, char **argv)
{
  char *mm = 0, *p;
  int size = 8000, overlap;
  p = malloc (1);

  while (mm < p) {
mm = malloc (16777216);
if (mm == 0) {
  printf ("not enough memory to run test\n");
  exit (0);
}
printf ("malloc (16777216) = %d\n", (int)mm);
  }
  while ((p = malloc (size))) {
overlap = (int)p + size - (int)mm;
if (p < mm && overlap > 0) {
  printf ("overlap = %d\n", overlap);
  exit (1);
}
  }
  return 0;
}


The 16MB malloc's are large enough to get malloc to mmap the memory
for the buffer.  Initially, the pointers returned are below the 1-byte
buffer, but eventually one will be returned that is above it.  Then
the 8436 byte malloc's fill up the space between the 1 byte buffer and
the last mmap'ed buffer until either the buffer returned overlaps the
mmap'ed buffer, or it runs out of memory.
The printf that prints out the 16MB buffer pointers seems to be
required in order for the code to exhibit the problem.
If I use sizes much larger than 8000 for the last malloc's, it will
segfault, and this is the traceback I get from gdb:
#0  0x610404be in mktime () from /usr/bin/cygwin1.dll
#1  0x61040e55 in mktime () from /usr/bin/cygwin1.dll
#2  0x610415e8 in cygwin1!calloc () from /usr/bin/cygwin1.dll
#3  0x61041f7d in strdup () from /usr/bin/cygwin1.dll
#4  0x61042a1d in strdup () from /usr/bin/cygwin1.dll
#5  0x61043444 in mmap64 () from /usr/bin/cygwin1.dll
#6  0x61043849 in mmap () from /usr/bin/cygwin1.dll
#7  0x610401bc in mktime () from /usr/bin/cygwin1.dll
#8  0x61040413 in mktime () from /usr/bin/cygwin1.dll
#9  0x610413e6 in malloc () from /usr/bin/cygwin1.dll
#10 0x00401169 in main (argc=1, argv=0xa041418) at malloc_bug.c:21
I notice that malloc calls mmap which then calls calloc.  Is the
malloc code sufficiently re-entrant for that to work?




Cygwin Win95/NT Configuration Diagnostics
Current System Time: Wed Aug 20 15:49:18 2003
Windows XP Professional Ver 5.1 Build 2600 Service Pack 1

Path:   D:\cygwin\usr\X11R6\bin
D:\cygwin\usr\local\bin
D:\cygwin\bin
D:\cygwin\bin
c:\emacs-20.7\bin
D:\cygwin\bin
D:\cygwin\usr\X11R6\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
d:\New_Data_Entry\cygwin
\\Nt2\nt2_D\Microsoft Visual Studio\VC98\BIN
\\Nt2\nt2_D\Microsoft Visual Studio\MSDEV98\BIN
D:\cygwin\bin\id.exe output (nontsec)
UID: 1004(roconnor)  GID: 513(None)
513(None)
D:\cygwin\bin\id.exe output (ntsec)
UID: 1004(roconnor)  GID: 513(None)
544(Administrators)  545(Users)
SysDir: C:\WINDOWS\System32
WinDir: C:\WINDOWS
HOME = `D:\cygwin\home\roconnor'
MAKE_MODE = `unix'
PWD = `/home/roconnor/cw/malloc_bug'
USER = `roconnor'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users.WINDOWS'
APPDATA = `C:\Documents and Settings\roconnor.DELWIN\Application Data'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `DELWIN'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
DISPLAY = `127.0.0.1:3.0'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\roconnor.DELWIN'
LESS = `-c'
LOGNAME = `roconnor'
LOGONSERVER = `\\DELWIN'
MANPATH = `:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/cygdrive/a'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 1 Stepping 2, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0102'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
SESSIONNAME = `Console'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `c:\DOCUME~1\ROCONN~1.DEL\LOCALS~1\Temp'
TERM = `xterm'
TMP = `c:\DOCUME~1\ROCONN~1.DEL\LOCALS~1\Temp'
USERDOMAIN = `DELWIN'
USERNAME = `roconnor'
USERPROFILE = `C:\Documents and Settings\roconnor.DELWIN'
WINDIR = `C:\WINDOWS'
WINDOWID = `2097166'
_ = `/usr/bin/cygcheck'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Option

Re: Win2k and cygwin memory leak

[Rolf Campbell]

Well, you could look at the task manager to see where all the memory is 
going (you can enable current memory allocation per process columns).

Also, you could use 'ps' to see if old cygwin processes are still running.

R. Boon wrote:
Hello list,

I noticed a problem with cygwin. It seems that some installations of
cygwin running on windows 2000 are leaking memory. The memory leak is
located in some kernel part of the operating system since it is not
cleaned up after all user space applications are close. 

This issue is reported previously to the cygwin list. This issue is
reported as a make failure:
http://www.cygwin.com/ml/cygwin/2003-04/msg02219.html
And as an issue with fork:
http://www.cygwin.com/ml/cygwin/2003-02/msg00551.html
I can confirm the reported symptoms. Every time I start a child process,
I loos some memory. Once all my memory and swap is depleted, I cannot
start new applications. Even closing running applications causes
trouble. A reboot is needed to restore the system. 

As an additional symptom I get the following question when I quit
cygwin. 
Terminate batch job (Y/N)?

This seems to indicate that child processes are not terminated and/or
completely removed from memory.
I tested this issue on four hosts
1. a Win2k SP4 with Cygwin 1.3.22 (128 Mb)
2. a Win2k SP4 with Cygwin 1.5.1 (128 Mb)
3. a Win2k SP4 with Cygwin 1.3.22 (192 Mb)
4. a Win2k SP4 with Cygwin 1.3.22 (256 Mb) <- not affected
Host nr. 4 is not affected by this issue. None of the tests lead to even
the slightest sign of a memory leak. All systems are installed with the
basic cygwin install using the setup.exe program from www.cygwin.com
Is there a solution to this issue that is never posted? Has anyone with
the same issue tried to fiddle with a memory limit setting of some sort?
(and did is work?)
Thank you for your time

greetings
Rogier


--
Unsubscribe info:  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: Backtick does not work

[Rolf Campbell]

That's not a bash script, that's an 'sh' script.  Which is ash on 
cygwin.  Maybe ash doesn't support back-tick?  If you change your 
/bin/sh to /bin/bash it should work.

Menon, Girish (MED, WIPRO-GE MED) wrote:
From the bash shell the ` (backtick or command execution) work. But when
I spawn a process and execute a shell script which contains the back
ticks, the process just chokes.
For example, a simple shell script like
#!/bin/sh
..
..
myenv=`/bin/env | grep CYGWIN`
..
..
I am able to execute this script properly from the bash shell (as any
user on the system). I am not getting any error at all from the
execution of the script. It just quits. I checked the error code too. It
is 0.
But this same script when executed via a spawned process does not work.
Any help?

Girish





--
Unsubscribe info:  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 Compiling hello world C Program.

[Rolf Campbell]

Well, to start, that's not a valid C-program.
To end, http://www.cygwin.com/problems.html
Jag wrote:
Hi,

I have downloaded cygwin onto one of my pcs, but when i try to compile a
simple program, I get loads of errors
hello.c is

#include 
#include 
#include 
printf("Hello World\n");
exit 0;
when i do
gcc -c hello.c, i get the following output
In file included from hello.c:1:
/usr/include/stdio.h:34:20: stddef.h: No such file or directory
/usr/include/stdio.h:37:20: stdarg.h: No such file or directory
In file included from /usr/include/sys/reent.h:14,
from /usr/include/stdio.h:45,
from hello.c:1:
/usr/include/sys/_types.h:22:20: stddef.h: No such file or directory
In file included from /usr/include/sys/reent.h:14,
from /usr/include/stdio.h:45,
from hello.c:1:
/usr/include/sys/_types.h:30: parse error before "wint_t"
/usr/include/sys/_types.h:32: parse error before '}' token
/usr/include/sys/_types.h:33: parse error before '}' token
In file included from /usr/include/stdio.h:45,
from hello.c:1:
/usr/include/sys/reent.h:570: parse error before "_mbstate_t"
/usr/include/sys/reent.h:576: parse error before "_mbrlen_state"
/usr/include/sys/reent.h:577: parse error before "_mbrtowc_state"
/usr/include/sys/reent.h:578: parse error before "_mbsrtowcs_state"
/usr/include/sys/reent.h:579: parse error before "_wcrtomb_state"
/usr/include/sys/reent.h:580: parse error before "_wcsrtombs_state"
/usr/include/sys/reent.h:591: parse error before '}' token
/usr/include/sys/reent.h:605: parse error before '}' token
In file included from /usr/include/stdio.h:46,
from hello.c:1:
/usr/include/sys/types.h:55:21: stddef.h: No such file or directory
In file included from hello.c:1:
/usr/include/stdio.h:176: parse error before "size_t"
/usr/include/stdio.h:182: parse error before "__gnuc_va_list"
/usr/include/stdio.h:183: parse error before "__gnuc_va_list"
/usr/include/stdio.h:184: parse error before "__gnuc_va_list"
/usr/include/stdio.h:196: parse error before "fread"
/usr/include/stdio.h:197: parse error before "fwrite"
/usr/include/stdio.h:217: parse error before "__gnuc_va_list"
/usr/include/stdio.h:222: parse error before "__gnuc_va_list"
/usr/include/stdio.h:223: parse error before "size_t"
/usr/include/stdio.h:224: parse error before "__gnuc_va_list"
/usr/include/stdio.h:225: parse error before "__gnuc_va_list"
/usr/include/stdio.h:226: parse error before "__gnuc_va_list"
/usr/include/stdio.h:229: parse error before "size_t"
/usr/include/stdio.h:280: parse error before "size_t"
/usr/include/stdio.h:285: parse error before "__gnuc_va_list"
/usr/include/stdio.h:286: parse error before "__gnuc_va_list"
/usr/include/stdio.h:287: parse error before "__gnuc_va_list"
/usr/include/stdio.h:288: parse error before "__gnuc_va_list"
/usr/include/stdio.h:289: parse error before "size_t"
/usr/include/stdio.h:290: parse error before "__gnuc_va_list"
/usr/include/stdio.h:291: parse error before "__gnuc_va_list"
/usr/include/stdio.h:292: parse error before "__gnuc_va_list"
/usr/include/stdio.h:294: parse error before "size_t"
/usr/include/stdio.h:295: parse error before "size_t"
In file included from hello.c:2:
/usr/include/stdlib.h:14:20: stddef.h: No such file or directory
In file included from hello.c:2:
/usr/include/stdlib.h:62: parse error before "size_t"
/usr/include/stdlib.h:63: parse error before "__nmemb"
/usr/include/stdlib.h:73: parse error before "__size"
/usr/include/stdlib.h:74: parse error before "size_t"
/usr/include/stdlib.h:75: parse error before "size_t"
/usr/include/stdlib.h:76: parse error before '*' token
/usr/include/stdlib.h:77: parse error before "wchar_t"
/usr/include/stdlib.h:78: parse error before "wchar_t"
/usr/include/stdlib.h:79: parse error before "wchar_t"
/usr/include/stdlib.h:80: parse error before "mbstowcs"
/usr/include/stdlib.h:81: parse error before "_mbstowcs_r"
/usr/include/stdlib.h:82: parse error before "wcstombs"
/usr/include/stdlib.h:83: parse error before "_wcstombs_r"
/usr/include/stdlib.h:90: parse error before "size_t"
/usr/include/stdlib.h:90: parse error before ')' token
/usr/include/stdlib.h:92: parse error before "size_t"
In file included from hello.c:3:
/usr/include/string.h:14:20: stddef.h: No such file or directory
In file included from hello.c:3:
/usr/include/string.h:22: parse error before "size_t"
/usr/include/string.h:23: parse error before "size_t"
/usr/include/string.h:24: parse error before "size_t"
/usr/include/string.h:25: parse error before "size_t"
/usr/include/string.h:26: parse error before "size_t"
/usr/include/string.h:32: parse error before "strcspn"
/usr/include/string.h:34: parse error before "strlen"
/usr/include/string.h:35: parse error before "size_t"
/usr/include/string.h:36: parse error before "size_t"
/usr/include/string.h:37: parse error before "size_t"
/usr/include/string.h:40: parse error before "strspn"
/usr/include/string.h:47: parse error before "strxfrm"
/usr/include/string.h:52: parse error before "size_t"
/usr/include/string.h:53: parse error before "siz

Re: ash 20020731-3 and/or cygwin 1.5.2 directory vs. executable problem

[Rolf Campbell]

Jason Tishler wrote:

Corinna,

On Mon, Aug 11, 2003 at 09:05:39PM +0200, Corinna Vinschen wrote:

On Mon, Aug 11, 2003 at 02:06:13PM -0400, Jason Tishler wrote:

Since the source of ash 20020731-1 seems identical to ash
20020731-3, this seems to indicate a build and/or cygwin problem...
It's a situation which is determined by coincidence...
Huh?
I think it has to do with which dir-entry appears first.  Or something 
like that.  It has been mentioned before that this is a known limitation 
of cygwin.



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

Re: cygwin as a replacement for explorer.exe

[Rolf Campbell]

S. L. wrote:
Ralf,
[...]
If you're asking whether you can replace the Explorer desktop,
taskbar,

and window manager with Cygwin tools/programs, I'm not sure if it's
possible
This is one of the goals of the KDE/cygwin project.
[...]

I think you and Igor gave a too complicated answer.
The short one is: yes, one can replace the shell=Explorer.exe from [boot] in
system.ini with cygwin application. In fact, I tested it with my favourite
shortcut line that launches rxvt.
So, after the login completed, there was only my background, no desktop, no
bars but only the rxvt window. The problems with this approach are:
1. the application used as shell must also be able to
logoff/shutdown/restart/standby/restart in MS-Dos mode; or a batch file that starts 
after the (in
my case) rxvt window, the corresponding window dialog.
There is a cygwin 'shutdown' command.  It lets you do everything except 
restart in MS-DOS mode.



--
Unsubscribe info:  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: Win2k and cygwin memory leak

[Rolf Campbell]

This may be a Win2000 problem, not a cygwin problem...What service pack 
are you running?

You can try one more thing:  after you run out of memory and kill 
mozilla, exit all your cygwin processes, and check to see if the 
cygwin1.dll file is locked (try renaming it using windows explorer, but, 
remember to restore it's original name after).

Then open another bash shell and check the memory info.

R. Boon wrote:

I've inserted the results of my test in this message. First the status
before the test, then the status after the test. Also I've used mozilla
as memory buffer. When the system fails and I close an application, like
mozilla, I can execute commands again. 
As you can see, ps shows no additional processes or defunct or zombie
processes. I've used the task manager to make a list of all processes
sorted by memory like you said. I can see the processes appearing and
disappearing in the task manager list, yet the memory usage is still
rising.

$ ps ax
  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
 1604   11604   1604  con 11130 12:16:27 /usr/bin/bash
 146016041460   1212  con 11130 12:17:16 /usr/bin/ps
$ cat /proc/version
CYGWIN_NT-5.0 1.3.22(0.78/3/2) 2003-03-18 09:20
$ cat /proc/stat
cpu 318507 0 284388 2892208
page 51683 11605
swap 51683 11504
intr 669529
ctxt 5585091
btime 1060247997
$ cat /proc/meminfo
 total:  used:  free:
Mem:   199802880  119267328   80535552
Swap:  448077824  147505152  300572672
MemTotal: 195120 kB
MemFree:   78648 kB
MemShared: 0 kB
HighTotal: 0 kB
HighFree:  0 kB
LowTotal: 195120 kB
LowFree:   78648 kB
SwapTotal:437576 kB
SwapFree: 293528 kB
$ ./do_stuff
...
$ ps ax
 12 [main] bash 1520 sync_with_child: child 27440(0x240) died before
initialization with status code 0x80
   3529 [main] bash 1520 sync_with_child: *** child state waiting for
longjmp
bash: fork: Resource temporarily unavailable
$ killall mozilla

$ ps ax
  PIDPPIDPGID WINPID  TTY  UIDSTIME COMMAND
 1520   11520   1520  con 11130 12:55:03 /usr/bin/bash
 134015201340  22624  con 11130 13:57:23 /usr/bin/ps
$ cat /proc/meminfo
 total:  used:  free:
Mem:   199802880  170090496   29712384
Swap:  448077824  230862848  217214976
MemTotal: 195120 kB
MemFree:   29016 kB
MemShared: 0 kB
HighTotal: 0 kB
HighFree:  0 kB
LowTotal: 195120 kB
LowFree:   29016 kB
SwapTotal:437576 kB
SwapFree: 212124 kB
$ cat /proc/stat
cpu 409418 0 831625 2718088
page 9 28248
swap 9 28208
intr 928431
ctxt 8388379
btime 1060253518


--
Unsubscribe info:  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: Win2k and cygwin memory leak

[Rolf Campbell]

Christopher Faylor wrote:
As described, the memory leak is obviously not in cygwin.  It is in
windows.  I was adding some clarification to the issue by changing a
"may be" to a "definitely is".
I think that this kind of clarification is more useful than your
message, which essentially says "If we could figure out what was causing
the problem then maybe it could be fixed".  Personally, I don't see how
that observation is useful.
Having had some experience with this, I find it highly doubtful that any
useful data will come from people posting their "me too" experiences.
If someone wants to fix this then researching the Microsoft Knowledge
Base might be a place to start.  A google search might also be helpful.
Could it be *possible* that cygwin leaves some memory allocated?  Does 
windows claim to free all memory allocated by a process when it exits? 
What about cygwin shared memory?

I'm not claiming it's a cygwin problem, I'm just curious.

-Rolf



--
Unsubscribe info:  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.1 issue?

[Rolf Campbell]

I have seen this as well.  Difficult to reproduce (seems to work 
correctly > 99% of the time).  I was running a 1.5.0 snapshot (from 
several weeks ago) when I saw it.

Charles Wilson wrote:
When (re)compiling some of my packages, I noticed that (some) signals 
are not being propagated to children.

That is:

$ ./my-package-ver-rel.sh build
Hit ^C
I'm returned to my bash prompt, but the make continues in the background.

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

2.05b-11 doesn't display prompt with hidden characters correctly

[Rolf Campbell]

I just upgraded my bash to 2.05b-11.  I use ANSI color codes in my PS1 
prompt, and in 2.05-10, they worked fine.  Now with -11, if I hit 
'cn', I expect to see:

/home/rcampbell> c
Display all 190 possibilities? (y or n)
/home/rcampbell> c
But, instead, I see:
/home/rcampbell> c
Display all 190 possibilities? (y or n)
/home/rcampbell> c c
And, at this point, bash seems confused about where the cursor is 
located.  Backspace can only kill the 2nd 'c', the space and first 'c' 
are permenent until it draws a new prompt.

This also happens if the list of possibilities is displayed (with or 
without the question).

-Rolf

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Sun Aug 03 12:07:46 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\WINNT\SYSTEM32
C:\WINNT
C:\WINNT\SYSTEM32\WBEM
C:\PERFORCE
C:\cygwin\bin
C:\WINNT\system32
C:\WINNT
C:\WINNT\System32\Wbem
C:\Perforce
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\Program Files\SSH
C:\cygwin\usr\X11R6\bin

C:\cygwin\bin\id.exe output (nontsec)
UID: 11643(rcampbell)   GID: 10513(Domain
groups=544(Administrators)  
545(Users)  10513(Domain Users)

C:\cygwin\bin\id.exe output (ntsec)
UID: 11643(rcampbell)   GID: 10513(Domain
groups=544(Administrators)  
545(Users)  10513(Domain Users)

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

CYGWIN = `binmode'
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp'
USER = `rcampbell'

ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `PCRCAMPBELL2'
COMSPEC = `C:\WINNT\system32\cmd.exe'
COSMIC = `c:/node.beta1/COSMIC'
DISPLAY = `:0'
HOMEDRIVE = `C:'
HOMEPATH = `\'
LOGONSERVER = `\\PCRCAMPBELL2'
MANPATH = `:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/home/rcampbell'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSE_ROOT = `C:\OSE\OSE4.4.1\'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyc;.pyo;.pyw;.pys'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0806'
PROGRAMFILES = `C:\Program Files'
PS1 = `\[\]$PWD\[\]>\[\] '
SHLVL = `2'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `C:\Temp'
TERM = `xterm'
TEXMF = `{/usr/share/lilypond/1.6.11,/usr/share/texmf}'
TROPIC_UNIQUE_ID = `150'
USERDNSDOMAIN = `tropicnetworks.com'
USERDOMAIN = `TROPICNETWORKS'
USERNAME = `rcampbell'
USERPROFILE = `C:\Documents and Settings\rcampbell'
WINDIR = `C:\WINNT'
WINDOWID = `168046576'
_ = `/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `C:'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start 
Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:/cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:/cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:/cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS   19069Mb  80% CP CS UN PA FC Campbell
d:  cd   N/AN/A

C: /cuserbinmode
.  /cygdrive userbinmode,cygdrive
C:/cygwin  / system  binmode
C:/cygwin/bin  /usr/bin  system  binmode
C:/cygwin/lib  /usr/lib  system  binmode
C:\cygwin\usr\X11R6\lib\X11\fonts  /usr/X11R6/lib/X11/fonts  system  binmode
.  /cygdrive system  binmode,cygdrive

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: 

Re: FAQ page margin width issue

[Rolf Campbell]

Larry Hall wrote:
Brian Dessent wrote:

On cygwin.com, there are two versions of the FAQ page.  The first is
 and is the direct output of texi2html.
The second is  which is the same
content except the texi2html output is in a TABLE, with the standard
Cygwin.com navbar on the left (also a TABLE, with the width="20%"
attribute.)
I don't know about you all but I find this second "faq0.html" version
nearly useless because there is (at least) one question that has a very
wide "program output" inside a PRE block tag.  This causes the margin
width to be about twice the width of my screen.  In the 'faq.html'
version that doesn't use tables, this is not a problem since the browser
renders the page sanely, i.e. everything -except- the one wide line is
wrapped to the actual screen width, but there is still a horizontal
scroll bar as that one section is wider than the rest.
However, when this content is included in a table cell as is the case
with 'faq0.html', it becomes very unfriendly, since that one table cell
must expand its width to fit the widest element.  In this case the
margins for the entire cell are adjusted to fit this one wide line,
which means that you have to scroll horizontally to read -any- answer
longer than a sentence or two.  I can't possibly see how anyone could
use this page in this format and not be highly annoyed, unless they have
a >= 1600px width screen and/or small fonts.
First of all, these aren't tables, they are frames.



Or don't use IE. ;-)

With Mozilla, the line you indicate is the only one that scrolls off
the right side of the page.  Actually, a quick check of IE 5.5 (yeah,
I know it's out of date but I don't use it so I don't care) shows me
the same result.  I know that doesn't help you much but...
I tried Mozilla 1.4 & IE 6.0, both render only one line past the visible 
screen.  Don't know what you are looking at.



--
Unsubscribe info:  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.0: rxvt copy/paste problems

[Rolf Campbell]

When I have CYGWIN=tty, I was able to reproduce the same exact problem.

David Rothenberger wrote:
I did some more testing.  The problem only occurs if CYGWIN=tty.
Without the tty option, everything works fine.
I'm having this problem on two separate Win2kPro SP4 machines.  I
did a clean Cygwin installation with only Base package this morning
and the problem still occurs.
Rolf, do you use "tty" in your CYGWIN variable?  If not, can you try
it?  If so, would you mind posting your cygcheck output, or emailing
it to me privately, so I can investigate further?
-Dave

Rolf Campbell writes:
 > I am unable to reproduce using 1.5.0/Win2000ProSp4
 > 
 > David Rothenberger wrote:
 > > I'm seeing some weird, new behavior with rxvt under cygwin-1.5.0-1
 > > related to copy/paste and its interaction with the Windows
 > > clipboard.  All of the weirdness described below goes away when I
 > > revert to 1.3.22.  I'm running under Win2k Pro SP4.
 > > 
 > > It seems that if I startup rxvt directly from Windows (Run box or
 > > cmd.exe shell), that rxvt works fine wrt copy/paste.  But, if I
 > > start bash or ash first, and then start rxvt from there, the rxvt
 > > copy/paste does not interact with the Windows clipboard at all.
 > > Also, it seems that two rxvt windows start from the same bash/ash
 > > process can copy/paste between one another, but not if they are
 > > started from a different bash/ash process.




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

Re: [PATCH] : make cygpath use multiple filename arguments

[Rolf Campbell]

What about filenames with spaces in them?  Wouldn't the output be ambiguous?

Mark Blackburn wrote:

Dunno if anybody will find this useful or not:

Currently if you say:

# cygpath -w /usr /lib

you get a usage error. With my patch you get:

# cygpath -w /usr /lib
c:\cygwin\usr c:\cygwin\lib
Mark.



Index: utils/cygpath.cc
===
RCS file: /cvs/src/src/winsup/utils/cygpath.cc,v
retrieving revision 1.28
diff -u -p -r1.28 cygpath.cc
--- utils/cygpath.cc	12 Jun 2003 20:40:58 -	1.28
+++ utils/cygpath.cc	17 Jul 2003 20:36:17 -
@@ -479,7 +479,7 @@ doit (char *filename)
 	}
 }
 
-  puts (buf);
+  printf ("%s", buf);
 }
 
 static void
@@ -675,11 +675,16 @@ main (int argc, char **argv)
   if (output_flag)
 	dowin (o);
 
-  if (optind != argc - 1)
+  if (optind > argc - 1)
 	usage (stderr, 1);
 
-  filename = argv[optind];
-  doit (filename);
+  for (int i=optind; argv[i]; i++) {
+	if (i != optind)
+	  printf(" ");
+	filename = argv[i];
+	doit (filename);
+  }
+  printf("\n");
 }
   else
 {




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

Re: Anyone trying 1.5.0 for anything other than managed mode?

[Rolf Campbell]

Gary R. Van Sickle wrote:
I've been using 1.5.0 for my large build environment since it was
released.  No problems yet.


Same story here, with one exception, discussed later.  I used all the latest
[test] libs, bash, etc at work all day today, rebuilt gcc from cvs,
re-autox-ed source trees, everything works.
The exception: The "-" and "+" keys on the keypad are giving me *two* "-"'s or
"+"'s at the bash prompt.  The "/" and "*" keys are fine, as are the rest of the
keypad keys, and the non-keypad "+" and "-".  It's not the new bash, since I'm
seeing it at home too and I don't have the new bash here yet.
I see the same thing here.



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

Re: Anyone trying 1.5.0 for anything other than managed mode?

[Rolf Campbell]

I've been using 1.5.0 for my large build environment since it was 
released.  No problems yet.  (in fact, I notice the speed improvement 
over 1.3.22 -- you know, that sparse file thing).

Christopher Faylor wrote:
Can I take the silence on bug reports for anything other than managed
mode as a good sign.
The list of packages built with 1.5.0 is growing.  I hope we'll see a
list of available packages here (and maybe in cygwin-announce) we reach
critical mass.
cgf
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to [EMAIL PROTECTED]
and be permanently blocked from mailing lists at sources.redhat.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/

Re: Backing up cygwin

[Rolf Campbell]

Luciano wrote:
Well, thanks for making me aware of the other two things that he 
mentioned, although I still have no idea of what he is talking about 
:-)

Now, why not store these things in goold old fuzzy and warm text 
files? Registry sucks, and it sucks badly.
The reason why the mount table cannot be stored in a file is: where 
would this file be located?  It couldn't be under the cygwin "/" path 
because, without the mount table, you don't know where that is.

And besides, CygWin is set of windows programs and it's normal for 
windows programs to use the registry (and faster than text files).



--
Unsubscribe info:  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.0: rxvt copy/paste problems

[Rolf Campbell]

I am unable to reproduce using 1.5.0/Win2000ProSp4

David Rothenberger wrote:
I'm seeing some weird, new behavior with rxvt under cygwin-1.5.0-1
related to copy/paste and its interaction with the Windows
clipboard.  All of the weirdness described below goes away when I
revert to 1.3.22.  I'm running under Win2k Pro SP4.
It seems that if I startup rxvt directly from Windows (Run box or
cmd.exe shell), that rxvt works fine wrt copy/paste.  But, if I
start bash or ash first, and then start rxvt from there, the rxvt
copy/paste does not interact with the Windows clipboard at all.
Also, it seems that two rxvt windows start from the same bash/ash
process can copy/paste between one another, but not if they are
started from a different bash/ash process.
Here's an example.  From a DOS box, run 

  rxvt -e /bin/sh

That rxvt works fine for copying and pasting.  (I tried copy/paste
to/from Notepad.)
Now, from a DOS box, run

  sh

or

  bash --norc --noprofile

and then from the shell prompt, start two copies of rxvt:

  rxvt -e /bin/sh &
  rxvt -e /bin/sh &
Neither of those rxvt windows will copy/paste to the Windows
clipboard.  But, they will copy/paste between one another.
Now, from one of those rxvt windows, start another two rxvt windows:

  rxvt -e /bin/sh &
  rxvt -e /bin/sh &
Neither of those two new windows can copy/paste with Windows
clipboard or with the previously started two windows, but they can
copy/paste between one another.
One other observation.  If I start rxvt directly from a DOS box, and
then start additional rxvt windows from the first rxvt window, all
windows can copy/paste with the Windows clipboard and between one
another.
David


--
Unsubscribe info:  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: Restricted

[Rolf Campbell]

Martin Gainty wrote:
Hello All-

Anyone run across the keywork 'restricted'?
What does it mean?
Many Thanks,
-Martin
It means that children must be accompanied by an adult.



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

website broken

[Rolf Campbell]

When I view "www.cygwin.com", I get an empty page.

/home/rcampbell> wget -S www.cygwin.com
--16:57:26--  http://www.cygwin.com/
   => `index.html'
Resolving www.cygwin.com... done.
Connecting to www.cygwin.com[66.187.233.205]:80... connected.
HTTP request sent, awaiting response...
End of file while parsing headers.
Retrying.
/home/rcampbell> telnet www.cygwin.com 80
Trying 66.187.233.205...
Connected to www.cygwin.com.
Escape character is '^]'.
Connection closed by foreign host.


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

Sparse file performance (Was: Re: Sparse file criteria malfunction- binutils produces sparse .exe & .dll files)

[Rolf Campbell]

Christopher Faylor wrote:
I remade the executables in an old version of inetutils.
The numbers below show that only the larger ones are sparse
(so the relative overhead is small) and that stripping them
removes sparseness. 


This is exactly the kind of data I was looking for.  It seems to me that
this suggests that there really is no issue that we have to worry about
in this case.
Out of curiousity, does building the executable 1) without debugging options,
and 2) with the -s option, also result in non-sparse files?
I'll test this myself when I get back to a windows computer but that won't
be for some time.
I really appreciate your checking into this, Pierre.

cgf
I did some profiling of sparse-files vs. non-sparse files.  I found that 
accessing sparse files is between 5% and 10% slower (on 1.3.22/Win2000).

I created a 3Meg, 6Meg, 10Meg and 40Meg file using cp /dev/zero.  I then 
copied each file using windows explorer (and then verified that the 
sparse bit was gone).

Then I ran 'time cat filename > /dev/null'  (i ran it a few times to 
make sure the file was cached).  The performance difference was:

40Meg: 5%
10Meg: 7%
6Meg: 10%
3Meg:  5%
This wasn't the most sofisticated test ever, I did not ensure that the 
files were equally fragmented on disk.  But, it does show that sparse 
files are notably slower.



--
Unsubscribe info:  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: Updated: perl-5.8.0-2

[Rolf Campbell]

Gerrit P. Haase wrote:
Hallo Rolf,
So, I've recieved confirmation that this problem is only with cygwin
perl, and not with GNU/Linux perl (5.8).
So, please file a bugreport, perlbug is included in the dist.

Gerrit
Which ports is perlbug for?



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Updated: perl-5.8.0-2

[Rolf Campbell]

Gerrit P. Haase wrote:
Hallo Rolf,
TEST.PL:
1:#!/bin/perl
2:$/ = "\r\n";
3:
4:open( LOG, ";
9:print $in;
Ok, so you get the same results as me.  They are both wrong.  The script 
should only print the first line.


I just tried something, I made a file like this: "000   a   b   c 
\r  \r  \n   d   e   f  \r  \r  \n".  Then the perl script shows only 
the first line.


In 5.6: setting 'binmode LOG, ":crlf";' would set the line-separator to 
"\r\n".
In 5.8: setting 'binmode LOG, ":crlf";' sets the line-separator to "\r" 
+ $/.  So, given that I've already set the line-separator to "\r\n" it 
ends up as "\r\r\n" for that file.
What about removing line #6 and let Perl do the conversion:
Gerrit
I know that there are ways to write the script so that it avoids the 
problem.  I've converted the script into python anyways (partially 
because of this problem).  So, it's not like this problem is halting my 
work or anything, I just think it's strange that cygwin perl operates 
differently than Linux perl (when run on a bin-mode mount).

I just wanted to point out this bug in the cygwin port.

-Rolf



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Updated: perl-5.8.0-2

[Rolf Campbell]

Rolf Campbell wrote:
Gerrit P. Haase wrote:

Hallo Rolf,
Am Dienstag, 1. April 2003 um 18:13 schriebst du:
Gerrit P. Haase wrote:

Rolf schrieb:

So, is this a cygwin perl problem?  Or has the stock perl decided
to only work with magic ENV variables?


I don't see the problem in the latest Perl (5.9.0) and I'm trying to
figure out how it can be fixed, in the meantime, please try to use the
magic PERLIO=perlio setting for your environment.
Gerrit
Ok, using PERLIO=perlio, but I'm still having a problem (which worked 
in the previous version of Perl).


TEST.PL:
1:#!/bin/perl
2:$/ = "\r\n";
3:
4:open( LOG, ";
9:print $in;



in (od -c in):
000   a   b   c  \r  \n   d   e   f  \r  \n
012



This is on a BINMODE mount.  This script outputs "000   a   b   c 
\n   d   e   f  \n".  If I go back to prev Perl, OR remove line#2 OR 
remove line#6, then it outputs "000   a   b   c  \n"


1. No PERLIO setting:

$ od -c in
000   a   b   c  \r  \n   a   b   c  \r  \n
012
$ ./crlf.pl 2>&1 | tee log.in
abc
abc
$ od -c log.in
000   a   b   c  \r  \n   a   b   c  \r  \n
012
2. PERLIO=perlio:

$ export PERLIO=perlio

$ ./crlf.pl 2>&1 | tee log.in
abc
abc
$ od -c log.in
000   a   b   c  \n   a   b   c  \n
010
3. PERLIO=raw:

$ export PERLIO=raw

$ ./crlf.pl 2>&1 | tee log.in
abc
abc
$ od -c log.in
000   a   b   c  \n   a   b   c  \n
010
4. PERLIO=stdio:

$ export PERLIO=stdio

$ ./crlf.pl 2>&1 | tee log.in
abc
abc
$ od -c log.in
000   a   b   c  \n   a   b   c  \n
010
5. PERLIO=:

$ export PERLIO=

$ ./crlf.pl 2>&1 | tee log.in
abc
abc
$ od -c log.in
000   a   b   c  \r  \n   a   b   c  \r  \n
012
Gerrit


Ok, so you get the same results as me.  They are both wrong.  The script 
should only print the first line.

I just tried something, I made a file like this: "000   a   b   c 
\r  \r  \n   d   e   f  \r  \r  \n".  Then the perl script shows only 
the first line.

In 5.6: setting 'binmode LOG, ":crlf";' would set the line-separator to 
"\r\n".
In 5.8: setting 'binmode LOG, ":crlf";' sets the line-separator to "\r" 
+ $/.  So, given that I've already set the line-separator to "\r\n" it 
ends up as "\r\r\n" for that file.

Does anybody have access to a U/Linux machine with perl 5.8 on it?  Can 
they run that test script on it?  I'd like to know if this is only a 
problem with cygwin-perl or with perl in general.
So, I've recieved confirmation that this problem is only with cygwin 
perl, and not with GNU/Linux perl (5.8).



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Updated: perl-5.8.0-2

[Rolf Campbell]

Gerrit P. Haase wrote:
Hallo Rolf,
Am Dienstag, 1. April 2003 um 18:13 schriebst du:
Gerrit P. Haase wrote:
Rolf schrieb:
So, is this a cygwin perl problem?  Or has the stock perl decided
to only work with magic ENV variables?
I don't see the problem in the latest Perl (5.9.0) and I'm trying to
figure out how it can be fixed, in the meantime, please try to use the
magic PERLIO=perlio setting for your environment.
Gerrit
Ok, using PERLIO=perlio, but I'm still having a problem (which worked in 
the previous version of Perl).

TEST.PL:
1:#!/bin/perl
2:$/ = "\r\n";
3:
4:open( LOG, ";
9:print $in;


in (od -c in):
000   a   b   c  \r  \n   d   e   f  \r  \n
012


This is on a BINMODE mount.  This script outputs "000   a   b   c 
\n   d   e   f  \n".  If I go back to prev Perl, OR remove line#2 OR 
remove line#6, then it outputs "000   a   b   c  \n"


1. No PERLIO setting:

$ od -c in
000   a   b   c  \r  \n   a   b   c  \r  \n
012
$ ./crlf.pl 2>&1 | tee log.in
abc
abc
$ od -c log.in
000   a   b   c  \r  \n   a   b   c  \r  \n
012
2. PERLIO=perlio:

$ export PERLIO=perlio

$ ./crlf.pl 2>&1 | tee log.in
abc
abc
$ od -c log.in
000   a   b   c  \n   a   b   c  \n
010
3. PERLIO=raw:

$ export PERLIO=raw

$ ./crlf.pl 2>&1 | tee log.in
abc
abc
$ od -c log.in
000   a   b   c  \n   a   b   c  \n
010
4. PERLIO=stdio:

$ export PERLIO=stdio

$ ./crlf.pl 2>&1 | tee log.in
abc
abc
$ od -c log.in
000   a   b   c  \n   a   b   c  \n
010
5. PERLIO=:

$ export PERLIO=

$ ./crlf.pl 2>&1 | tee log.in
abc
abc
$ od -c log.in
000   a   b   c  \r  \n   a   b   c  \r  \n
012
Gerrit
Ok, so you get the same results as me.  They are both wrong.  The script 
should only print the first line.

I just tried something, I made a file like this: "000   a   b   c 
\r  \r  \n   d   e   f  \r  \r  \n".  Then the perl script shows only 
the first line.

In 5.6: setting 'binmode LOG, ":crlf";' would set the line-separator to 
"\r\n".
In 5.8: setting 'binmode LOG, ":crlf";' sets the line-separator to "\r" 
+ $/.  So, given that I've already set the line-separator to "\r\n" it 
ends up as "\r\r\n" for that file.

Does anybody have access to a U/Linux machine with perl 5.8 on it?  Can 
they run that test script on it?  I'd like to know if this is only a 
problem with cygwin-perl or with perl in general.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: setup.exe troubleshooting snapshot

[Rolf Campbell]

Max Bowsher wrote:
I've uploaded a new setup troubleshooting snapshot:
http://www.cygwin.com/setup-snapshots/setup-2.340.2.3-no-set_default_sec.exe
This is simply 2.340.2.3 with the recently-added ntsec code deactivated.
Please could anyone who can reproduce crashes with 2.340.2.3 give this a
try. If it doesn't crash, then we will have localized the problem to a small
area of code, so should have a good chance of finally locating the problem.
Max.
This version does not crash on my XP machine either.  I'll assume that 
the other 10 versions will act the same as on Marcel's machine.  I'll 
try the final version tonight.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

cygcheck: dump_sysinfo: GetVolumeInformation() failed (was: Re:Updated: perl-5.8.0-2)

[Rolf Campbell]

Frédéric L. W. Meunier wrote:
Rolf Campbell wrote:


/home/rcampbell> cygcheck -svr > /tmp/cygcheck.txt
cygcheck: dump_sysinfo: GetVolumeInformation() failed: 53


I got

$ cygcheck -svr > /tmp/cygcheck.txt
cygcheck: dump_sysinfo: GetVolumeInformation() failed: 1005
cygcheck: dump_sysinfo: GetVolumeInformation() failed: 1005
cygcheck: dump_sysinfo: GetVolumeInformation() failed: 1005
This only happens when I run cygcheck while I'm not connected to my 
corporate LAN.  I think it has to do with accessing mounted network drives.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Aliases no longer defined?

[Rolf Campbell]

Peter Davis wrote:


To recap, this same exact .bashrc file used to work, on my previous
Windows(2000) machine. Now, on WinXP, it doesn't.  In fact, even if I
explicitly type "source~/.bashrc" at the shell prompt, it doesn't work. 
This is because ~ expands to ${HOME}, which is /cygdrive/c/home.

I don't get errors, but the aliases are not defined. That is the problem
I've been seeing. I'd like to have some aliases for common commands, and
I'd like to be able to set some environment variables, like adding some
dirctories to my path. (These don't need to be in the Windows-wide
path... just in Cygwin.) Also, copying .bashrc to .bash_profile and then
starting a new bash shell doesn't work.
If anyone can tell me how to define these aliases and environment
variables, I'll be*very* grateful.


You can still set your HOME, there's nothing (that I know of!) wrong
with doing so.


Igor suggested that my $HOME is set wrong, although everything worked on
my old machine with this same setting.  What should this be, and how
should it get set?
You should not set it.  Cygwin will do it for you.

If you want Emacs to work, then set it to your real cygwin home, and 
move your .emacs* files into your real home dir. (That's the way I do it).



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Aliases no longer defined?

[Rolf Campbell]

[EMAIL PROTECTED] wrote:
On Tue, Apr 01, 2003 at 11:17:48AM -0500, Rolf Campbell wrote:

Peter Davis wrote:

Ok.  There ain't much worth cracking my system for anyway.  Here's the
/etc/passwd file from one machine below.
Thanks for any help with this!

-pd



SYSTEM:*:18:544:,S-1-5-18::
Administrators:*:544:544:,S-1-5-32-544::
Administrator:unused_by_nt/2000/xp:500:513:U-WINBOX-XPRO\Administrator,S-1-5-21-3996086570-211328594-3762194425-500:/home/Administrator:/bin/bash
Guest:unused_by_nt/2000/xp:501:513:U-WINBOX-XPRO\Guest,S-1-5-21-3996086570-211328594-3762194425-501:/home/Guest:/bin/bash
HelpAssistant:unused_by_nt/2000/xp:1004:513:Remote Desktop Help Assistant 
Account,U-WINBOX-XPRO\HelpAssistant,S-1-5-21-3996086570-211328594-3762194425-1004:/home/HelpAssistant:/bin/bash
pdavis:unused_by_nt/2000/xp:1006:513:Peter 
Davis,U-WINBOX-XPRO\pdavis,S-1-5-21-3996086570-211328594-3762194425-1006:/home/pdavis:/bin/bash
Peter Davis:unused_by_nt/2000/xp:1005:513:U-WINBOX-XPRO\Peter 
Davis,S-1-5-21-3996086570-211328594-3762194425-1005:/home/Peter 
Davis:/bin/bash
SUPPORT_388945a0:unused_by_nt/2000/xp:1002:513:CN=Microsoft 
Corporation,L=Redmond,S=Washington,C=US,U-WINBOX-XPRO\SUPPORT_388945a0,S-1-5-21-3996086570-211328594-3762194425-1002:/home/SUPPORT_388945a0:/bin/bash
SUPPORT_3f151ab9:unused_by_nt/2000/xp:1003:513:CN=Dell Computer 
Corporation,L=Round 
Rock,S=Texas,C=US,U-WINBOX-XPRO\SUPPORT_3f151ab9,S-1-5-21-3996086570-211328594-3762194425-1003:/home/SUPPORT_3f151ab9:/bin/bash
Pdavis:unused_by_nt/2000/xp:11059:10513:Pdavis,U-WORKDOM\Pdavis,S-1-5-21-138833350-1684557462-623647154-1059:/cygdrive/c/Documents and Settings/Pdavis.WORKDOM:/bin/bash
Well, you seem to have 3 accounts, one with a space in it, and one with 
different case.  Do you really have 3 different accounts?


I only have one account on this machine.  I'm not sure how the others
got created.  The one with the space may have been created by the Palm
desktop software, since that's the name I use for sync'ing.
I don't know about the other two.

Is there something about this file that would prevent my
bashrc/.bash_profile from defining aliases?
-pd
No, *BUT*, you said you tried "source ~/.bashrc", and this would be 
loading "/cygdrive/c/home/.bashrc", *not* 
"/cygdrive/c/home/pdavis/.bashrc".  I would suggest re-creating your 
/etc/passwd file from scratch.  Back up your current one and re-run 
setup (no need to install anything new).



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Aliases no longer defined?

[Rolf Campbell]

Igor Pechtchanski wrote:
On Tue, 1 Apr 2003, Rolf Campbell wrote:


Peter Davis wrote:

Ok.  There ain't much worth cracking my system for anyway.  Here's the
/etc/passwd file from one machine below.
Thanks for any help with this!

-pd

SYSTEM:*:18:544:,S-1-5-18::
Administrators:*:544:544:,S-1-5-32-544::
Administrator:unused_by_nt/2000/xp:500:513:U-WINBOX-XPRO\Administrator,S-1-5-21-3996086570-211328594-3762194425-500:/home/Administrator:/bin/bash
Guest:unused_by_nt/2000/xp:501:513:U-WINBOX-XPRO\Guest,S-1-5-21-3996086570-211328594-3762194425-501:/home/Guest:/bin/bash
HelpAssistant:unused_by_nt/2000/xp:1004:513:Remote Desktop Help Assistant 
Account,U-WINBOX-XPRO\HelpAssistant,S-1-5-21-3996086570-211328594-3762194425-1004:/home/HelpAssistant:/bin/bash
pdavis:unused_by_nt/2000/xp:1006:513:Peter 
Davis,U-WINBOX-XPRO\pdavis,S-1-5-21-3996086570-211328594-3762194425-1006:/home/pdavis:/bin/bash
Peter Davis:unused_by_nt/2000/xp:1005:513:U-WINBOX-XPRO\Peter 
Davis,S-1-5-21-3996086570-211328594-3762194425-1005:/home/Peter Davis:/bin/bash
SUPPORT_388945a0:unused_by_nt/2000/xp:1002:513:CN=Microsoft 
Corporation,L=Redmond,S=Washington,C=US,U-WINBOX-XPRO\SUPPORT_388945a0,S-1-5-21-3996086570-211328594-3762194425-1002:/home/SUPPORT_388945a0:/bin/bash
SUPPORT_3f151ab9:unused_by_nt/2000/xp:1003:513:CN=Dell Computer Corporation,L=Round 
Rock,S=Texas,C=US,U-WINBOX-XPRO\SUPPORT_3f151ab9,S-1-5-21-3996086570-211328594-3762194425-1003:/home/SUPPORT_3f151ab9:/bin/bash
Pdavis:unused_by_nt/2000/xp:11059:10513:Pdavis,U-WORKDOM\Pdavis,S-1-5-21-138833350-1684557462-623647154-1059:/cygdrive/c/Documents
 and Settings/Pdavis.WORKDOM:/bin/bash
Well, you seem to have 3 accounts, one with a space in it, and one with
different case.  Do you really have 3 different accounts?


Rolf,

And what does this have to do with aliases not being exported?  FWIW, the
UIDs on all 3 accounts are different...
Well, if he *thinks* he's logging on as 'pdavis', but is really logging 
on as 'Pdavis', then bash might be using the 'wrong' home dir.

Peter,
what happens if you ". /home/pdavis/.bashrc" (without using ~)


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Aliases no longer defined?

[Rolf Campbell]

Peter Davis wrote:
Ok.  There ain't much worth cracking my system for anyway.  Here's the
/etc/passwd file from one machine below.
Thanks for any help with this!

-pd



SYSTEM:*:18:544:,S-1-5-18::
Administrators:*:544:544:,S-1-5-32-544::
Administrator:unused_by_nt/2000/xp:500:513:U-WINBOX-XPRO\Administrator,S-1-5-21-3996086570-211328594-3762194425-500:/home/Administrator:/bin/bash
Guest:unused_by_nt/2000/xp:501:513:U-WINBOX-XPRO\Guest,S-1-5-21-3996086570-211328594-3762194425-501:/home/Guest:/bin/bash
HelpAssistant:unused_by_nt/2000/xp:1004:513:Remote Desktop Help Assistant 
Account,U-WINBOX-XPRO\HelpAssistant,S-1-5-21-3996086570-211328594-3762194425-1004:/home/HelpAssistant:/bin/bash
pdavis:unused_by_nt/2000/xp:1006:513:Peter 
Davis,U-WINBOX-XPRO\pdavis,S-1-5-21-3996086570-211328594-3762194425-1006:/home/pdavis:/bin/bash
Peter Davis:unused_by_nt/2000/xp:1005:513:U-WINBOX-XPRO\Peter 
Davis,S-1-5-21-3996086570-211328594-3762194425-1005:/home/Peter Davis:/bin/bash
SUPPORT_388945a0:unused_by_nt/2000/xp:1002:513:CN=Microsoft 
Corporation,L=Redmond,S=Washington,C=US,U-WINBOX-XPRO\SUPPORT_388945a0,S-1-5-21-3996086570-211328594-3762194425-1002:/home/SUPPORT_388945a0:/bin/bash
SUPPORT_3f151ab9:unused_by_nt/2000/xp:1003:513:CN=Dell Computer Corporation,L=Round 
Rock,S=Texas,C=US,U-WINBOX-XPRO\SUPPORT_3f151ab9,S-1-5-21-3996086570-211328594-3762194425-1003:/home/SUPPORT_3f151ab9:/bin/bash
Pdavis:unused_by_nt/2000/xp:11059:10513:Pdavis,U-WORKDOM\Pdavis,S-1-5-21-138833350-1684557462-623647154-1059:/cygdrive/c/Documents
 and Settings/Pdavis.WORKDOM:/bin/bash
Well, you seem to have 3 accounts, one with a space in it, and one with 
different case.  Do you really have 3 different accounts?



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Updated: perl-5.8.0-2

[Rolf Campbell]

Gerrit P. Haase wrote:
Rolf schrieb:
So, is this a cygwin perl problem?  Or has the stock perl decided
to only work with magic ENV variables?
I don't see the problem in the latest Perl (5.9.0) and I'm trying to
figure out how it can be fixed, in the meantime, please try to use the
magic PERLIO=perlio setting for your environment.
Gerrit
Ok, using PERLIO=perlio, but I'm still having a problem (which worked in 
the previous version of Perl).

TEST.PL:
1:#!/bin/perl
2:$/ = "\r\n";
3:
4:open( LOG, ";
9:print $in;
in (od -c in):
000   a   b   c  \r  \n   d   e   f  \r  \n
012
This is on a BINMODE mount.  This script outputs "000   a   b   c 
\n   d   e   f  \n".  If I go back to prev Perl, OR remove line#2 OR 
remove line#6, then it outputs "000   a   b   c  \n"



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: bash hang ( G:\Cygwin\bin\find.exe: *** WFSO timed out for afterlongjmp)

[Rolf Campbell]

Elfyn McBratney wrote:
Hi,

I've seen this quite a lot of hangs over the last 3-4 months when doing
large find's and it's not always easy reproduce and normally occurs when
find has finished and returned, but not always. If you run the following
from a bash prompt (seen it in cmd.exe and rxvt) and run the following
$ find /usr/include -name "*.h" -exec fprep "_t" {} \;
 ^???

After that has returned if you wait for 30-60 seconds you may see the above
message. If not try a few times, same intervals and it should crop up, but
like I said it's not always easy to reproduce. It's not damaging as a ^C
will break free of it, just wanted to let you know I'm seeing it. :-) It's
coming from sync_with_parent in fork.cc ...
Just tried it 5 times, never had any problems...



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Aliases no longer defined?

[Rolf Campbell]

Peter Davis wrote:
On Mon, 31 Mar 2003 18:15:13 -0500
Rolf Campbell <[EMAIL PROTECTED]> wrote:

Peter Davis wrote:

I recently switched from Windows NT4 and Windows 2000 to Windows XP.  I
installed cygwin freshly on both systems.  Now I'm noticing that on both
systems, .bashrc seems to be completely ignored.  I haven't changed this
file at all, but suddenly the aliases I define and export are not
defined when I try to type them at the shell prompt.
If I do

	source ~/.bashrc

it works without error, but the aliases are *still* not defined.  I
noticed by running 'cygcheck -s' that the new systems seem to have DLL
build 1.3.22 (3/18/2003), while the older ones were running build 1.3.20
(2/18/2003).  However, nothing else has changed.  This used to work, but
now doesn't.
Any clues?

Thanks,

-pd
What does your /etc/passwd look like?


It's got a bunch of entries: SYSTEM, Administrators, Administrator, Guest, pdavis, etc.

What should I be looking for?
can you post the content?



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Aliases no longer defined?

[Rolf Campbell]

Igor Pechtchanski wrote:
P.S. On an unrelated note, the use of shell functions is recommended over
the use of aliases.
Why is that?



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Aliases no longer defined?

[Rolf Campbell]

Peter Davis wrote:
I recently switched from Windows NT4 and Windows 2000 to Windows XP.  I
installed cygwin freshly on both systems.  Now I'm noticing that on both
systems, .bashrc seems to be completely ignored.  I haven't changed this
file at all, but suddenly the aliases I define and export are not
defined when I try to type them at the shell prompt.
If I do

	source ~/.bashrc

it works without error, but the aliases are *still* not defined.  I
noticed by running 'cygcheck -s' that the new systems seem to have DLL
build 1.3.22 (3/18/2003), while the older ones were running build 1.3.20
(2/18/2003).  However, nothing else has changed.  This used to work, but
now doesn't.
Any clues?

Thanks,

-pd
What does your /etc/passwd look like?



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

OT: disk structure (was Re: Determining the location of a Cygwininstallation)

[Rolf Campbell]

Hannu E K Nevalainen (garbage mail) wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
Of Rolf Campbell


Software packages belong in  C:\Program\*  and nowhere else
(Note that this

is equal to "C:\Program Files\*" on ENGLISH Win98.
Ahhh... yeah.  So, what is the rest of the disk for?  Why not just put
everything in a directory called "C:\Everything"?


 Ahh... Microsoft infestation detected. ;-)

 I should have written  "C:\Program\\"  above...
Happy now?
 I _hate_ having C:\foo\ c:\bar\ c:\this\ c:\that\ directories. They DO
belong in C:\Program\ (or whatever) _AND NOT IN THE ROOT_ >:-I
 Any files belonging to a software package should be kept in a storage that
identifies them as beeing part of that package. IMO a well structured
operating system allows this (e.g. AmigaOS, Unix/Linux)
 Therefore cygwin is in C:\Program\cygwin\ here. As it has kept all its
files within that directory I consider it to be "well behaving". (i.e. I
talk good about it among friends ;-)
 Example: Install Corel Draw (Version 8 is the last one I tried), tell it to
install in C:\Program\CorelDraw\ - what does it do? It STILL creates a
C:\corel\ directory; to hold some "essential" files.
/Hannu E K Nevalainen, Mariefred, Sweden

--END OF MESSAGE--
While I agree that not all programs should have a root dir, what's in 
yours?  "Program", "Documents and Settings", "WINNT"?  All that means is 
that instead of having 35 root dirs, you have 3 root dirs and 33 dirs in 
"Program".  That is no better (unless you are running FAT16).

And Linux doesn't give you anything better, they just call "Program 
Files" "/bin".

I like to have (and used to have) a more functionally structured disk: 
in "C:\", I had: "Programming", "Courses", "Internet", "AudioVideo", etc...



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Updated: perl-5.8.0-2

[Rolf Campbell]

Gerrit P. Haase wrote:
Hallo Rolf,

Am Montag, 31. März 2003 um 19:47 schriebst du:


Gerrit P. Haase wrote:

perl-5.8.0-2 release has been uploaded to sourceware
  -- it should be on the mirrors soon.

Also, when I ran cygcheck, I got:
cygcheck: dump_sysinfo: GetVolumeInformation() failed: 53
How do you run cygcheck?

Gerrit
/home/rcampbell> cygcheck -svr > /tmp/cygcheck.txt
cygcheck: dump_sysinfo: GetVolumeInformation() failed: 53


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Corrected: setup.exe beta (testing needed - really!)

[Rolf Campbell]

Max Bowsher wrote:
Rolf Campbell wrote:
Max Bowsher wrote:
Robert Collins wrote:
On Thu, 2003-03-27 at 22:10, Vince Hoffman wrote:
Ok, well this is 'not good' :}.

At what point does it crash?

At start before any window appears.
Shuttting down cygwin services made no difference.
let me know if there is any more i can do to help the problem.
Hmm, I don't think there is much more you can do. Max can reproduce it..
Not well, and not with -O0, though.
Vince, would you be able to test the -O0 snapshot with debug symbols I've
just uploaded? (bz2-ed to cut down on size of debug symbols).
Max.
I tested it on my home (XP) machine (which had a 100% crash rate on the
original), and the -O0 version works perfectly.
This bug gets more and more elusive. Plus, I had to reinstall Windows on my
desktop, and I can no-longer reproduce the crash.
Rolf, is Service Pack 1 installed on your home machine?
Max.
Yes.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/