cygtclsh80 child processes -- Update

Fri Sep 10 15:08:00 GMT 1999

I did some more experimenting since posting my
original question. I think the problem may be caused
by some weird interaction between Tcl and the shell.
Consider the following hypothetical session under the
bash shell:
 $ cygtclsh80
 % exec ls
 % exit
 $ ps
The ps output shows one zombie 'ls' process. But try
this:
 $ cygtclsh80
 % ls
 % exit
 $ ps
There's still only one zombie process, the original
one. So the culprit is 'exec ls', not just plain
'ls'.
That puzzled me. I thought Tcl's 'unknown' proc
translated 'ls' to 'exec ls'. Shouldn't they be
equivalent?
But when I looked at 'unknown' I discovered they were
not. 'unknown' converts 'ls' to:
 exec >&@stdout OTHER-STUFF ls
The '>&@stdout' appears to be the key:
 $ cygtclsh80
 % exec >&@stdout ls; # Ok
 % exec >&file ls; # Zombie
 % exit
I can't use '>&@stdout' for my application, however,
so I had to hunt for other solutions.
I thought maybe bash didn't realize that 'ls' had
closed its standard output. I decided to see if
running 'ls' like this would help:
 $ cygtclsh80
 % exec bash -c ls
 % exit
 $ ps
It did. No new zombies. Perhaps the rule is:
 Replace
 exec COMMAND ARGS
 With
 exec bash -c {COMMAND ARGS}
But then I had a rude awakening:
 $ cygtclsh80
 % exec bash -c pwd
 % exit
 $ ps
At this point I had the zombie 'ls' process plus a new
zombie 'pwd' process. FYI, this works:
 $ cygtclsh80
 % pwd
 % exit
 $ ps
but as I said, it doesn't help me.
Some more experimenting led me to an ugly solution for
this too:
 bash -c "bash -c pwd"
This "bash"es the 'pwd' into submission. :-)
The rule appears to be:
 Replace
 exec COMMAND ARGS
 With
 bash -c {COMMAND ARGS}; # if COMMAND is ordinary
 With
 bash -c {bash -c {COMMAND ARGS}}; # otherwise 
Let's summarize:
 $ cygtclsh80
 % ls; # ok
 % pwd; # ok
 % exec ls; # zombie
 % exec pwd; # zombie
 % exec bash -c ls; # ok
 % exec bash -c pwd; # zombie
 % exec bash -c {bash -c pwd} # ok
 % exit
Can anyone explain why this is happening? Tcl's
'exec' documentation warns that an application can
hang in 16-bit DOS mode under Windows 95 but I'm
running in NT so this caveat doesn't seem to apply.
===
-- 
Opinions expressed above are not necessarily my employer's.
James M. Stern
ITG Inc. Culver City, CA (213) 270-7955
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com