Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <19990910220701.3927.rocketmail@web1401.mail.yahoo.com>
Date: Fri, 10 Sep 1999 15:07:01 -0700 (PDT)
From: James Stern <jsternitg AT yahoo DOT com>
Reply-To: stern AT itginc DOT com
Subject: cygtclsh80 child processes -- Update
To: cygwin <cygwin AT sourceware DOT cygnus DOT com>
Cc: stern AT itginc DOT com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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