Mail Archives: cygwin/1999/09/10/18:09:50
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 AT sourceware DOT cygnus DOT com
- Raw text -