public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Windows update vs. cygrunsrv
@ 2005-10-12 15:45 Eric Blake
  2005-10-12 16:05 ` Tim Prince
                   ` (5 more replies)
  0 siblings, 6 replies; 20+ messages in thread
From: Eric Blake @ 2005-10-12 15:45 UTC (permalink / raw)
  To: Cygwin List

I don't know it this was unique to my machine, but am
reporting it in case anyone else runs into the same
issue.  When running Microsoft update today, on Win2k,
the patch for Security Update for DirectX 9 for Windows
2000 (KB904706) hung during installation, with an
instance of cygrunsrv hogging 100% CPU, until I had
stopped every last one of my cygrunsrv processes.  I
don't know what the Microsoft update was trying to do
to running services during the update, but it obviously
didn't interact very well with cygrunsrv.

Anyways, since stopping everything allowed the installation
to proceed, and the required reboot brought up a working
system, I don't know if it is worth trying to patch cygrunsrv
to behave nicer in the presence of whatever the Windows
upgrade was throwing at it.  Rather, I'm just posting this
as a sort of FYI for anyone else that might encounter the
same behavior.

--
Eric Blake

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Windows update vs. cygrunsrv
  2005-10-12 15:45 Windows update vs. cygrunsrv Eric Blake
@ 2005-10-12 16:05 ` Tim Prince
  2005-10-12 16:08 ` Corinna Vinschen
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 20+ messages in thread
From: Tim Prince @ 2005-10-12 16:05 UTC (permalink / raw)
  To: Eric Blake; +Cc: Cygwin List

Eric Blake wrote:

> When running Microsoft update today, on Win2k,
> the patch for Security Update for DirectX 9 for Windows
> 2000 (KB904706) hung during installation, with an
> instance of cygrunsrv hogging 100% CPU, until I had
> stopped every last one of my cygrunsrv processes.  I
> don't know what the Microsoft update was trying to do
> to running services during the update, but it obviously
> didn't interact very well with cygrunsrv.
I don't think the Microsoft update process is compatible even with 
running Microsoft applications, so I make a practice of shutting cygwin 
down entirely.  I ran the updates, including Office 2003SP2, without 
major incident yesterday, on Win2K, WinXP-32, and WinXP-64, total of 4 
installations, with cygwin installed but shut down.  It did take over an 
hour on the system which is on an ordinary DSL line.  There were plenty 
of pop-ups interspersed on the XP systems, about RealPlayer needing an 
update but the site being down, or CA anti-virus not being in a mode 
acceptable to Microsoft.  As you know, Microsoft is not very sympathetic 
to people who want to avoid down time for applications not purchased 
from them.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Windows update vs. cygrunsrv
  2005-10-12 15:45 Windows update vs. cygrunsrv Eric Blake
  2005-10-12 16:05 ` Tim Prince
@ 2005-10-12 16:08 ` Corinna Vinschen
  2005-10-12 16:35 ` Rolf Campbell
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 20+ messages in thread
From: Corinna Vinschen @ 2005-10-12 16:08 UTC (permalink / raw)
  To: Cygwin List

On Oct 12 15:45, Eric Blake wrote:
> I don't know it this was unique to my machine, but am
> reporting it in case anyone else runs into the same
> issue.  When running Microsoft update today, on Win2k,
> the patch for Security Update for DirectX 9 for Windows
> 2000 (KB904706) hung during installation, with an
> instance of cygrunsrv hogging 100% CPU, until I had
> stopped every last one of my cygrunsrv processes.  I
> don't know what the Microsoft update was trying to do
> to running services during the update, but it obviously
> didn't interact very well with cygrunsrv.

I have the converse experience.  I'm usually running three services
under cygrunsrv (syslogd, sshd, esd) and today I used Windows Update,
too, to get the latest security bugfixes.  I had (and never had)
problems to do this while my services were still running.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat, Inc.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Windows update vs. cygrunsrv
  2005-10-12 15:45 Windows update vs. cygrunsrv Eric Blake
  2005-10-12 16:05 ` Tim Prince
  2005-10-12 16:08 ` Corinna Vinschen
@ 2005-10-12 16:35 ` Rolf Campbell
  2005-10-12 18:03 ` Mike Stockman
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 20+ messages in thread
From: Rolf Campbell @ 2005-10-12 16:35 UTC (permalink / raw)
  To: cygwin

Eric Blake wrote:
> I don't know it this was unique to my machine, but am
> reporting it in case anyone else runs into the same
> issue.  When running Microsoft update today, on Win2k,
> the patch for Security Update for DirectX 9 for Windows
> 2000 (KB904706) hung during installation, with an
> instance of cygrunsrv hogging 100% CPU, until I had
> stopped every last one of my cygrunsrv processes.  I
> don't know what the Microsoft update was trying to do
> to running services during the update, but it obviously
> didn't interact very well with cygrunsrv.
> 
> Anyways, since stopping everything allowed the installation
> to proceed, and the required reboot brought up a working
> system, I don't know if it is worth trying to patch cygrunsrv
> to behave nicer in the presence of whatever the Windows
> upgrade was throwing at it.  Rather, I'm just posting this
> as a sort of FYI for anyone else that might encounter the
> same behavior.

I updated 3 machines: 2 XP boxes an 1 Win2k box.  All 3 were running 
cygrunsrv and sshd.  I only experienced problems on the Win2k box. 
cygrunsrv hogged the cpu until I killed it, then sshd hogged the cpu 
until I killed it.  After killing those processes, the update proceeded 
without issue and after the restart everything (including ssh) was 
working fine.


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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Windows update vs. cygrunsrv
  2005-10-12 15:45 Windows update vs. cygrunsrv Eric Blake
                   ` (2 preceding siblings ...)
  2005-10-12 16:35 ` Rolf Campbell
@ 2005-10-12 18:03 ` Mike Stockman
  2005-10-12 20:14   ` Gerrit P. Haase
  2005-10-12 22:24 ` Brian Dessent
  2005-10-15 16:55 ` Where is documentation on bash "wait"? Siegfried Heintze
  5 siblings, 1 reply; 20+ messages in thread
From: Mike Stockman @ 2005-10-12 18:03 UTC (permalink / raw)
  To: cygwin

Eric Blake wrote:
> I don't know it this was unique to my machine, but am
> reporting it in case anyone else runs into the same
> issue.  When running Microsoft update today, on Win2k,
> the patch for Security Update for DirectX 9 for Windows
> 2000 (KB904706) hung during installation, with an
> instance of cygrunsrv hogging 100% CPU, until I had
> stopped every last one of my cygrunsrv processes.  I
> don't know what the Microsoft update was trying to do
> to running services during the update, but it obviously
> didn't interact very well with cygrunsrv.

I have encountered this on a Windows 2000 system whenever I 
install/uninstall Apple's iTunes and QuickTime. I end up with cygrunsrv 
using all CPU time and when I kill it, the Apple installation fails. No 
idea why... the only way past this was to manually uninstall the Apple 
products and reinstall them.

Not sure what the pattern is here, but it's one more piece of data...

Mike


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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Windows update vs. cygrunsrv
  2005-10-12 18:03 ` Mike Stockman
@ 2005-10-12 20:14   ` Gerrit P. Haase
  0 siblings, 0 replies; 20+ messages in thread
From: Gerrit P. Haase @ 2005-10-12 20:14 UTC (permalink / raw)
  To: cygwin

Mike Stockman wrote:
> Eric Blake wrote:
> 
>> I don't know it this was unique to my machine, but am
>> reporting it in case anyone else runs into the same
>> issue.  When running Microsoft update today, on Win2k,
>> the patch for Security Update for DirectX 9 for Windows
>> 2000 (KB904706) hung during installation, with an
>> instance of cygrunsrv hogging 100% CPU, until I had
>> stopped every last one of my cygrunsrv processes.  I
>> don't know what the Microsoft update was trying to do
>> to running services during the update, but it obviously
>> didn't interact very well with cygrunsrv.

I saw similar problems when running process explorer, IIRC the
affected service was cygserver, though I'm not sure.  This leads
to my thought that the tool to discover malicious software may
be the culprit since it scans all running processes, may be the
DirectX setup performs similar scans?


Gerrit

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Windows update vs. cygrunsrv
  2005-10-12 15:45 Windows update vs. cygrunsrv Eric Blake
                   ` (3 preceding siblings ...)
  2005-10-12 18:03 ` Mike Stockman
@ 2005-10-12 22:24 ` Brian Dessent
  2005-10-13 13:49   ` Pavel Tsekov
  2005-10-15 16:55 ` Where is documentation on bash "wait"? Siegfried Heintze
  5 siblings, 1 reply; 20+ messages in thread
From: Brian Dessent @ 2005-10-12 22:24 UTC (permalink / raw)
  To: Cygwin List

Eric Blake wrote:

> I don't know it this was unique to my machine, but am
> reporting it in case anyone else runs into the same
> issue.  When running Microsoft update today, on Win2k,
> the patch for Security Update for DirectX 9 for Windows
> 2000 (KB904706) hung during installation, with an
> instance of cygrunsrv hogging 100% CPU, until I had
> stopped every last one of my cygrunsrv processes.  I
> don't know what the Microsoft update was trying to do
> to running services during the update, but it obviously
> didn't interact very well with cygrunsrv.

That's odd, I installed all 9 of yesterday's Patch Tuesday updates and
none of them hung.  I had 3 or 4 cygwin services running at the time.

Brian

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Windows update vs. cygrunsrv
  2005-10-12 22:24 ` Brian Dessent
@ 2005-10-13 13:49   ` Pavel Tsekov
  2005-10-18 16:56     ` Jason Pyeron
  0 siblings, 1 reply; 20+ messages in thread
From: Pavel Tsekov @ 2005-10-13 13:49 UTC (permalink / raw)
  To: Cygwin List

On Wed, 12 Oct 2005, Brian Dessent wrote:

> Eric Blake wrote:
>
> > I don't know it this was unique to my machine, but am
> > reporting it in case anyone else runs into the same
> > issue.  When running Microsoft update today, on Win2k,
> > the patch for Security Update for DirectX 9 for Windows
> > 2000 (KB904706) hung during installation, with an
> > instance of cygrunsrv hogging 100% CPU, until I had
> > stopped every last one of my cygrunsrv processes.  I
> > don't know what the Microsoft update was trying to do
> > to running services during the update, but it obviously
> > didn't interact very well with cygrunsrv.

I've just installed this update too. cygrunsrv was using about 80 %
of the CPU while CSRSS.EXE was using what was left. Here are backtraces
from cygrunsrv and cygserver at the time the hang occured - both look
pretty strange, both indicate that the programs are stuck in NTDLL.DLL.

[cygrunsrv]

(gdb) thread 1
[Switching to thread 1 (thread 700.0x2b8)]#0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x7c5862e9 in ReadFile () from /mnt/c/WINNT/system32/KERNEL32.DLL
#2  0x000000f0 in ?? ()
#3  0x00000000 in ?? () from

(gdb) thread 2
[Switching to thread 2 (thread 700.0x2c4)]#0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x7c5862e9 in ReadFile () from /mnt/c/WINNT/system32/KERNEL32.DLL
#2  0x000000e8 in ?? ()
#3  0x00000000 in ?? () from

(gdb) thread 3
[Switching to thread 3 (thread 700.0x2c8)]#0  0x77f8287e in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f8287e in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x7c59a1af in WaitForMultipleObjectsEx () from /mnt/c/WINNT/system32/KERNEL32.DLL
#2  0x00000001 in ?? ()
#3  0x18bfed58 in ?? ()
#4  0x00000001 in ?? ()
#5  0x00000000 in ?? () from

[Switching to thread 4 (thread 700.0x2f0)]#0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x7c5862e9 in ReadFile () from /mnt/c/WINNT/system32/KERNEL32.DLL
#2  0x0000012c in ?? ()
#3  0x00000000 in ?? () from

(gdb) thread 5
[Switching to thread 5 (thread 700.0x780)]#0  0x77f813b2 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f813b2 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x7c57fe8f in KERNEL32!DebugActiveProcess () from /mnt/c/WINNT/system32/KERNEL32.DLL
#2  0x7c57fe66 in KERNEL32!DebugActiveProcess () from /mnt/c/WINNT/system32/KERNEL32.DLL
#3  0xffffffff in ?? ()
#4  0x192dffb4 in ?? ()
#5  0x61004055 in _cygtls::call2 (func=0, arg=0x0, buf=0x192deff0) at ../../../../src/winsup/cygwin/cygtls.cc:96
#6  0x00000000 in ?? () from


[cygserver]

Load new symbol table from "/usr/sbin/cygserver.exe"? (y or n) y
Reading symbols from /usr/sbin/cygserver.exe...done.
[Switching to thread 764.0x6fc]
(gdb) bt
#0  0x77f813b2 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0xffffffff in ?? ()
#2  0x1a7cffb4 in ?? ()
#3  0x61004055 in _cygtls::call2 (func=0, arg=0x0, buf=0x1a7ceff0) at ../../../../src/winsup/cygwin/cygtls.cc:96
#4  0x00000000 in ?? () from
(gdb) thread 2
[Switching to thread 2 (thread 764.0x2e8)]#0  0x77f82926 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82926 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x00000000 in ?? () from
(gdb) thread 3
[Switching to thread 3 (thread 764.0x2f4)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x00000000 in ?? () from
(gdb) thread 4
[Switching to thread 4 (thread 764.0x300)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x00000000 in ?? () from
(gdb) thread 5
[Switching to thread 5 (thread 764.0x304)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x00000000 in ?? () from
(gdb) thread 6
[Switching to thread 6 (thread 764.0x308)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x00000000 in ?? () from
(gdb) thread 6
[Switching to thread 6 (thread 764.0x308)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x00000000 in ?? () from
(gdb) thread 8
[Switching to thread 8 (thread 764.0x310)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x00000000 in ?? () from
(gdb) thread 9
[Switching to thread 9 (thread 764.0x314)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x00000000 in ?? () from
(gdb) thread 10
[Switching to thread 10 (thread 764.0x318)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
(gdb) bt
#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
#1  0x00000000 in ?? () from

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Where is documentation on bash "wait"?
  2005-10-12 15:45 Windows update vs. cygrunsrv Eric Blake
                   ` (4 preceding siblings ...)
  2005-10-12 22:24 ` Brian Dessent
@ 2005-10-15 16:55 ` Siegfried Heintze
  2005-10-15 18:12   ` Andrew DeFaria
  5 siblings, 1 reply; 20+ messages in thread
From: Siegfried Heintze @ 2005-10-15 16:55 UTC (permalink / raw)
  To: 'Cygwin List'

I tried info and man and could not find any information on wait. I want to
(using bash)

(1) How do I wait for multiple children and wake up when the first one dies?

(2) Examine the status code of the dead child and possibly spawn a new one?

Where is the documentation on wait?

Thanks,
Siegfried


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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Where is documentation on bash "wait"?
  2005-10-15 16:55 ` Where is documentation on bash "wait"? Siegfried Heintze
@ 2005-10-15 18:12   ` Andrew DeFaria
  0 siblings, 0 replies; 20+ messages in thread
From: Andrew DeFaria @ 2005-10-15 18:12 UTC (permalink / raw)
  To: cygwin

Siegfried Heintze wrote:
> I tried info and man and could not find any information on wait. I 
> want to (using bash)
>
> (1) How do I wait for multiple children and wake up when the first one 
> dies?
>
> (2) Examine the status code of the dead child and possibly spawn a new 
> one?
>
> Where is the documentation on wait?
Wait's a builtin so the documentation is in the bash(1) man page.
-- 
I like kids, but I don't think I could eat a whole one.


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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Windows update vs. cygrunsrv
  2005-10-13 13:49   ` Pavel Tsekov
@ 2005-10-18 16:56     ` Jason Pyeron
  0 siblings, 0 replies; 20+ messages in thread
From: Jason Pyeron @ 2005-10-18 16:56 UTC (permalink / raw)
  To: Cygwin List


Updating cygwin seemd to fix it, a client just called and indicated that 
her computer was "slow".

On Thu, 13 Oct 2005, Pavel Tsekov wrote:

> On Wed, 12 Oct 2005, Brian Dessent wrote:
>
>> Eric Blake wrote:
>>
>>> I don't know it this was unique to my machine, but am
>>> reporting it in case anyone else runs into the same
>>> issue.  When running Microsoft update today, on Win2k,
>>> the patch for Security Update for DirectX 9 for Windows
>>> 2000 (KB904706) hung during installation, with an
>>> instance of cygrunsrv hogging 100% CPU, until I had
>>> stopped every last one of my cygrunsrv processes.  I
>>> don't know what the Microsoft update was trying to do
>>> to running services during the update, but it obviously
>>> didn't interact very well with cygrunsrv.
>
> I've just installed this update too. cygrunsrv was using about 80 %
> of the CPU while CSRSS.EXE was using what was left. Here are backtraces
> from cygrunsrv and cygserver at the time the hang occured - both look
> pretty strange, both indicate that the programs are stuck in NTDLL.DLL.
>
> [cygrunsrv]
>
> (gdb) thread 1
> [Switching to thread 1 (thread 700.0x2b8)]#0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x7c5862e9 in ReadFile () from /mnt/c/WINNT/system32/KERNEL32.DLL
> #2  0x000000f0 in ?? ()
> #3  0x00000000 in ?? () from
>
> (gdb) thread 2
> [Switching to thread 2 (thread 700.0x2c4)]#0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x7c5862e9 in ReadFile () from /mnt/c/WINNT/system32/KERNEL32.DLL
> #2  0x000000e8 in ?? ()
> #3  0x00000000 in ?? () from
>
> (gdb) thread 3
> [Switching to thread 3 (thread 700.0x2c8)]#0  0x77f8287e in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f8287e in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x7c59a1af in WaitForMultipleObjectsEx () from /mnt/c/WINNT/system32/KERNEL32.DLL
> #2  0x00000001 in ?? ()
> #3  0x18bfed58 in ?? ()
> #4  0x00000001 in ?? ()
> #5  0x00000000 in ?? () from
>
> [Switching to thread 4 (thread 700.0x2f0)]#0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82926 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x7c5862e9 in ReadFile () from /mnt/c/WINNT/system32/KERNEL32.DLL
> #2  0x0000012c in ?? ()
> #3  0x00000000 in ?? () from
>
> (gdb) thread 5
> [Switching to thread 5 (thread 700.0x780)]#0  0x77f813b2 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f813b2 in HT_Get8BPPMaskPalette () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x7c57fe8f in KERNEL32!DebugActiveProcess () from /mnt/c/WINNT/system32/KERNEL32.DLL
> #2  0x7c57fe66 in KERNEL32!DebugActiveProcess () from /mnt/c/WINNT/system32/KERNEL32.DLL
> #3  0xffffffff in ?? ()
> #4  0x192dffb4 in ?? ()
> #5  0x61004055 in _cygtls::call2 (func=0, arg=0x0, buf=0x192deff0) at ../../../../src/winsup/cygwin/cygtls.cc:96
> #6  0x00000000 in ?? () from
>
>
> [cygserver]
>
> Load new symbol table from "/usr/sbin/cygserver.exe"? (y or n) y
> Reading symbols from /usr/sbin/cygserver.exe...done.
> [Switching to thread 764.0x6fc]
> (gdb) bt
> #0  0x77f813b2 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0xffffffff in ?? ()
> #2  0x1a7cffb4 in ?? ()
> #3  0x61004055 in _cygtls::call2 (func=0, arg=0x0, buf=0x1a7ceff0) at ../../../../src/winsup/cygwin/cygtls.cc:96
> #4  0x00000000 in ?? () from
> (gdb) thread 2
> [Switching to thread 2 (thread 764.0x2e8)]#0  0x77f82926 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82926 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x00000000 in ?? () from
> (gdb) thread 3
> [Switching to thread 3 (thread 764.0x2f4)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x00000000 in ?? () from
> (gdb) thread 4
> [Switching to thread 4 (thread 764.0x300)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x00000000 in ?? () from
> (gdb) thread 5
> [Switching to thread 5 (thread 764.0x304)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x00000000 in ?? () from
> (gdb) thread 6
> [Switching to thread 6 (thread 764.0x308)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x00000000 in ?? () from
> (gdb) thread 6
> [Switching to thread 6 (thread 764.0x308)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x00000000 in ?? () from
> (gdb) thread 8
> [Switching to thread 8 (thread 764.0x310)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x00000000 in ?? () from
> (gdb) thread 9
> [Switching to thread 9 (thread 764.0x314)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x00000000 in ?? () from
> (gdb) thread 10
> [Switching to thread 10 (thread 764.0x318)]#0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> (gdb) bt
> #0  0x77f82870 in RpcSsDontSerializeContext () from /mnt/c/WINNT/system32/NTDLL.DLL
> #1  0x00000000 in ?? () from
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Partner & Sr. Manager             7 West 24th Street #100     -
- +1 (443) 921-0381                 Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you 
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
is prohibited.

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Where is documentation on bash "wait"?
  2005-10-16 10:11       ` Dr. Volker Zell
@ 2005-10-16 21:09         ` Bas van Gompel
  0 siblings, 0 replies; 20+ messages in thread
From: Bas van Gompel @ 2005-10-16 21:09 UTC (permalink / raw)
  To: cygwin

Op Sun, 16 Oct 2005 12:11:00 +0200 schreef Dr. Volker Zell
in <82hdbh93gr.fsf@vzell-de.de.oracle.com>:
: >>>>> Buzz  writes:

:      > I was hoping for ``our'' man-maintainer, being much more knowledgeable
:      > about such issues, to be proactive...
:      > ...If (s)he isn't I'll look into finding the upstream ``man''-list.

:  I will forward this issues to the upstream man maintainer.

Great, thank you very much.


L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   /    /   really is |   and false bits entirely.    | mail for
  ) |  |  /    /    a 72 by 4 +-------------------------------+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."    | me. 4^re

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Where is documentation on bash "wait"?
  2005-10-16  4:01       ` Eric Blake
@ 2005-10-16 21:09         ` Bas van Gompel
  0 siblings, 0 replies; 20+ messages in thread
From: Bas van Gompel @ 2005-10-16 21:09 UTC (permalink / raw)
  To: cygwin

Op Sat, 15 Oct 2005 22:01:26 -0600 schreef Eric Blake
in <4351D096.2050403@byu.net>:
:  According to Buzz on 10/15/2005 9:46 PM:
[(possibly stale) bash.1 about somewhere.]

:  Hmm, I do have /usr/local/man on my manpath, and it did indeed have
:  man1/bash.1, but I don't know if that affected things.

I don't think so, as long bash_builins.1.gz didn't have the dirname in
the .so.

: > I'm curious how that's gonna work. My ``man'', after i've edited
: > bash_builtins.1(.gz) to mention man1/bash.1.gz me, says:
: >
: > | man1/bash.1.gz:1: warning: can't find character with input code 6
:
:  It seems like man can cope with a .so that points to a .gz if that is the
:  only line, but has problems if the .so points to a .gz when embedded in
:  remaining text.

That appears to be an accurate description of this issue.

:   I'm not familiar enough with man to know what is going on
:  here, but it does seem like a man issue.

Indeed (same here).

:   Meanwhile, I can distribute
:  bash.1 instead of bash.1.gz since that is all that works with the current
:  version of man.

That does WJFFM. Thanks a lot for your efforts.

[...]


L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   /    /   really is |   and false bits entirely.    | mail for
  ) |  |  /    /    a 72 by 4 +-------------------------------+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."    | me. 4^re

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Where is documentation on bash "wait"?
  2005-10-16  3:47     ` Buzz
  2005-10-16  4:01       ` Eric Blake
@ 2005-10-16 10:11       ` Dr. Volker Zell
  2005-10-16 21:09         ` Bas van Gompel
  1 sibling, 1 reply; 20+ messages in thread
From: Dr. Volker Zell @ 2005-10-16 10:11 UTC (permalink / raw)
  To: cygwin mailing-list

>>>>> Buzz  writes:

    > I was hoping for ``our'' man-maintainer, being much more knowledgeable
    > about such issues, to be proactive...
    > ...If (s)he isn't I'll look into finding the upstream ``man''-list.

I will forward this issues to the upstream man maintainer.

Ciao
  Volker


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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Where is documentation on bash "wait"?
  2005-10-16  3:47     ` Buzz
@ 2005-10-16  4:01       ` Eric Blake
  2005-10-16 21:09         ` Bas van Gompel
  2005-10-16 10:11       ` Dr. Volker Zell
  1 sibling, 1 reply; 20+ messages in thread
From: Eric Blake @ 2005-10-16  4:01 UTC (permalink / raw)
  To: cygwin mailing-list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Buzz on 10/15/2005 9:46 PM:
> 
> : > Do you have a copy of bash.1 lying around somewhere?
> :
> :  cygwin man pages are purposefully compressed, so it should be bash.1.gz.
> 
> I'm aware of that. I was WAGging you didn't get the error, having a
> (possibly stale) bash.1 about somewhere.

Hmm, I do have /usr/local/man on my manpath, and it did indeed have
man1/bash.1, but I don't know if that affected things.

> I'm curious how that's gonna work. My ``man'', after i've edited
> bash_builtins.1(.gz) to mention man1/bash.1.gz me, says:
> 
> | man1/bash.1.gz:1: warning: can't find character with input code 6

It seems like man can cope with a .so that points to a .gz if that is the
only line, but has problems if the .so points to a .gz when embedded in
remaining text.  I'm not familiar enough with man to know what is going on
here, but it does seem like a man issue.  Meanwhile, I can distribute
bash.1 instead of bash.1.gz since that is all that works with the current
version of man.

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

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

iD8DBQFDUdCW84KuGfSFAYARApvbAKDRDVPBqr1rkGCOreqJmYRnyXHnRwCgvIq9
n1NazcT+c9tdi+e2kjsttxw=
=LRRL
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Where is documentation on bash "wait"?
  2005-10-15 21:11   ` Eric Blake
@ 2005-10-16  3:47     ` Buzz
  2005-10-16  4:01       ` Eric Blake
  2005-10-16 10:11       ` Dr. Volker Zell
  0 siblings, 2 replies; 20+ messages in thread
From: Buzz @ 2005-10-16  3:47 UTC (permalink / raw)
  To: cygwin

Op Sat, 15 Oct 2005 15:11:53 -0600 schreef Eric Blake
in <43517099.5080908@byu.net>:
[Ahhh]
:
:  According to Bas van Gompel on 10/15/2005 2:46 PM:
: >
: > Did /you/ try it?
:
:  Yes, as bash maintainer, I /did/ try it.  However, I didn't realize that
:  there was a typo in the upstream bash_builtins.1 manpage; I just supposed
:  that the text that was there was all it needed - thanks for catching that,
:  and I will forward it upstream.

Thank you for doing this.

: > It complains about not finding bash.1.
:
:  I haven't seen man complain - I wonder what your setup is that got a
:  complaint about the typo in the .so?

I'd think it's quite normal... (On several systems) I get:
| <standard input>:14: can't open `bash.1': No such file or directory
| BASH_BUILTINS(1)                                              BASH_BUILTINS(1)
| [...]


: > Do you have a copy of bash.1 lying around somewhere?
:
:  cygwin man pages are purposefully compressed, so it should be bash.1.gz.

I'm aware of that. I was WAGging you didn't get the error, having a
(possibly stale) bash.1 about somewhere.

: > To get this to work as I think it is intended, I need to:
[...]
: > For some reason it doesn't work with a gzipped bash.1.
: > (A bug in man? It looks like it doesn't gunzip in this case.)
:
:  Yes, man could be improved to follow .so that have alternate extensions
:  (so that .so man1/bash.1 follows man1/bash.1.gz) - you may want to report
:  that to the upstream man list.

That would be even better. I was just thinking about having:
man1/bash.1.gz in the bash_builtins page (just like man1/wait.1
contains: ``.so man1/bash_builtins.1.gz'')

I was hoping for ``our'' man-maintainer, being much more knowledgeable
about such issues, to be proactive...
...If (s)he isn't I'll look into finding the upstream ``man''-list.

:  Meanwhile, I've corrected my local copy of bash to work in spite of the
:  cygwin gzipping; the next bash release will have the slick trick of inline
:  referencing to the bash builtins section, thanks to your patch pointing
:  that out to me.

I'm curious how that's gonna work. My ``man'', after i've edited
bash_builtins.1(.gz) to mention man1/bash.1.gz me, says:

| man1/bash.1.gz:1: warning: can't find character with input code 6
| man1/bash.1.gz:1: warning: can't find character with input code 3
| man1/bash.1.gz:1: warning: can't find character with input code 12
| man1/bash.1.gz:1: warning: can't find character with input code 127
| man1/bash.1.gz:1: warning [p 1, 2.3i]: cannot adjust line
| man1/bash.1.gz:1: warning [p 1, 2.5i]: cannot adjust line
| groff: troff: Signal 11
| grotty:<standard input>:163:warning: no final `x stop' command
| BASH_BUILTINS(1)                                              BASH_BUILTINS(1)
| [...]


L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   /    /   really is |   and false bits entirely.    | mail for
  ) |  |  /    /    a 72 by 4 +-------------------------------+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."    | me. 4^re

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Where is documentation on bash "wait"?
  2005-10-15 20:46 ` Bas van Gompel
@ 2005-10-15 21:11   ` Eric Blake
  2005-10-16  3:47     ` Buzz
  0 siblings, 1 reply; 20+ messages in thread
From: Eric Blake @ 2005-10-15 21:11 UTC (permalink / raw)
  To: cygwin mailing-list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bas van Gompel on 10/15/2005 2:46 PM:
> 
> Did /you/ try it?

Yes, as bash maintainer, I /did/ try it.  However, I didn't realize that
there was a typo in the upstream bash_builtins.1 manpage; I just supposed
that the text that was there was all it needed - thanks for catching that,
and I will forward it upstream.

> 
> It complains about not finding bash.1.

I haven't seen man complain - I wonder what your setup is that got a
complaint about the typo in the .so?

> Do you have a copy of bash.1 lying around somewhere?

cygwin man pages are purposefully compressed, so it should be bash.1.gz.

> 
> To get this to work as I think it is intended, I need to:
> 
> 
> For some reason it doesn't work with a gzipped bash.1.
> (A bug in man? It looks like it doesn't gunzip in this case.)

Yes, man could be improved to follow .so that have alternate extensions
(so that .so man1/bash.1 follows man1/bash.1.gz) - you may want to report
that to the upstream man list.

Meanwhile, I've corrected my local copy of bash to work in spite of the
cygwin gzipping; the next bash release will have the slick trick of inline
referencing to the bash builtins section, thanks to your patch pointing
that out to me.

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

Eric Blake             ebb9@byu.net
volunteer cygwin bash maintainer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDUXCZ84KuGfSFAYARAihEAJ9WEMJVS+MG74XExh+BS6fTAdI5xgCbB2QA
DE+hMj+DSE7yXs4Z/dqhrK0=
=d6U6
-----END PGP SIGNATURE-----

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* RE: Where is documentation on bash "wait"?
@ 2005-10-15 20:52 Stephan Mueller
  0 siblings, 0 replies; 20+ messages in thread
From: Stephan Mueller @ 2005-10-15 20:52 UTC (permalink / raw)
  To: cygwin mailing-list

Perhaps the problem is specific to your configuration -- man wait does
indeed point me to man bash, and the bash manpage does indeed cover wait
(I searched for SHELL BUILTIN COMMANDS based on early text in the page,
and then searched from the top of that section for wait -- worked like a
charm.

stephan();


-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf
Of Bas van Gompel
Sent: Saturday, October 15, 2005 1:46 PM
To: cygwin@cygwin.com
Subject: Re: Where is documentation on bash "wait"?

Op Sat, 15 Oct 2005 17:45:06 +0000 schreef Eric Blake
in
<101520051745.25630.43514022000160940000641E22007614380A050E040D0C079D0A
@comcast.net>:
[What the...]
: > I tried info and man and could not find any information on wait. I
want to
: > (using bash)
:
:  Did you try 'man wait'?  That would have pointed you to 'man bash',
where

Did /you/ try it?

It complains about not finding bash.1.
Do you have a copy of bash.1 lying around somewhere?

To get this to work as I think it is intended, I need to:

1) gunzip /usr/share/man/man1/bash.1.gz and
   /usr/share/man/man1/bash_builtins.1.gz

2) patch /usr/share/man/man1/bash_builtins.1 like so:
--- /usr/share/man/man1/bash_builtins.1~	2005-10-15
21:27:52.000000000 +0200
+++ /usr/share/man/man1/bash_builtins.1	2005-10-15 21:44:33.770000000
+0200
@@ -10,6 +10,6 @@
 ulimit, umask, unalias, unset, wait \- bash built-in commands, see
\fBbash\fR(1)
 .SH BASH BUILTIN COMMANDS
 .nr zZ 1
-.so bash.1
+.so man1/bash.1
 .SH SEE ALSO
 bash(1), sh(1)

3) re-gzip /usr/share/man/man1/bash_builtins.1, but not bash.1


For some reason it doesn't work with a gzipped bash.1.
(A bug in man? It looks like it doesn't gunzip in this case.)

[...]


L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   /    /   really is |   and false bits entirely.    | mail for
  ) |  |  /    /    a 72 by 4 +-------------------------------+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."    | me. 4^re

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


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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Where is documentation on bash "wait"?
  2005-10-15 17:45 Eric Blake
@ 2005-10-15 20:46 ` Bas van Gompel
  2005-10-15 21:11   ` Eric Blake
  0 siblings, 1 reply; 20+ messages in thread
From: Bas van Gompel @ 2005-10-15 20:46 UTC (permalink / raw)
  To: cygwin

Op Sat, 15 Oct 2005 17:45:06 +0000 schreef Eric Blake
in <101520051745.25630.43514022000160940000641E22007614380A050E040D0C079D0A@comcast.net>:
[What the...]
: > I tried info and man and could not find any information on wait. I want to
: > (using bash)
:
:  Did you try 'man wait'?  That would have pointed you to 'man bash', where

Did /you/ try it?

It complains about not finding bash.1.
Do you have a copy of bash.1 lying around somewhere?

To get this to work as I think it is intended, I need to:

1) gunzip /usr/share/man/man1/bash.1.gz and
   /usr/share/man/man1/bash_builtins.1.gz

2) patch /usr/share/man/man1/bash_builtins.1 like so:
--- /usr/share/man/man1/bash_builtins.1~	2005-10-15 21:27:52.000000000 +0200
+++ /usr/share/man/man1/bash_builtins.1	2005-10-15 21:44:33.770000000 +0200
@@ -10,6 +10,6 @@
 ulimit, umask, unalias, unset, wait \- bash built-in commands, see \fBbash\fR(1)
 .SH BASH BUILTIN COMMANDS
 .nr zZ 1
-.so bash.1
+.so man1/bash.1
 .SH SEE ALSO
 bash(1), sh(1)

3) re-gzip /usr/share/man/man1/bash_builtins.1, but not bash.1


For some reason it doesn't work with a gzipped bash.1.
(A bug in man? It looks like it doesn't gunzip in this case.)

[...]


L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   /    /   really is |   and false bits entirely.    | mail for
  ) |  |  /    /    a 72 by 4 +-------------------------------+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."    | me. 4^re

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Where is documentation on bash "wait"?
@ 2005-10-15 17:45 Eric Blake
  2005-10-15 20:46 ` Bas van Gompel
  0 siblings, 1 reply; 20+ messages in thread
From: Eric Blake @ 2005-10-15 17:45 UTC (permalink / raw)
  To: Siegfried Heintze, 'Cygwin List'

> I tried info and man and could not find any information on wait. I want to
> (using bash)

Did you try 'man wait'?  That would have pointed you to 'man bash', where
as a bash builtin, wait is properly documented.  Also, 'info bash' will tell you
about bash builtins, or you can try 'help wait' for a short synopsis.

> 
> (1) How do I wait for multiple children and wake up when the first one dies?

wait

> 
> (2) Examine the status code of the dead child and possibly spawn a new one?

I don't know of any way in POSIX to do this, but it is not really specific to
cygwin, so you might try asking a more appropriate mailing list.

--
Eric Blake
volunteer cygwin bash maintainer



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

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2005-10-18 16:56 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-10-12 15:45 Windows update vs. cygrunsrv Eric Blake
2005-10-12 16:05 ` Tim Prince
2005-10-12 16:08 ` Corinna Vinschen
2005-10-12 16:35 ` Rolf Campbell
2005-10-12 18:03 ` Mike Stockman
2005-10-12 20:14   ` Gerrit P. Haase
2005-10-12 22:24 ` Brian Dessent
2005-10-13 13:49   ` Pavel Tsekov
2005-10-18 16:56     ` Jason Pyeron
2005-10-15 16:55 ` Where is documentation on bash "wait"? Siegfried Heintze
2005-10-15 18:12   ` Andrew DeFaria
2005-10-15 17:45 Eric Blake
2005-10-15 20:46 ` Bas van Gompel
2005-10-15 21:11   ` Eric Blake
2005-10-16  3:47     ` Buzz
2005-10-16  4:01       ` Eric Blake
2005-10-16 21:09         ` Bas van Gompel
2005-10-16 10:11       ` Dr. Volker Zell
2005-10-16 21:09         ` Bas van Gompel
2005-10-15 20:52 Stephan Mueller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).