Date: Wed, 6 Jan 1999 11:41:29 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Tarragon Allen <075557 AT bud DOT cc DOT swin DOT edu DOT au>
cc: djgpp AT delorie DOT com
Subject: Re: Compiling BASH 2.02.1
In-Reply-To: <76uel1$o1o$1@lucille.cc.swin.edu.au>
Message-ID: <Pine.SUN.3.91.990106114109.8103T-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com


On 6 Jan 1999, Tarragon Allen wrote:

> Unfortunately also, SIGCLD is not defined anywhere in the djgpp header
> files.  I guess this makes sense, DOS not having the functionality to
> support child processes, etc.

DJGPP *does* support child processes (otherwise, how could a ported
Bash be useful?).  What DJGPP does NOT support is the signal called
SIGCLD or SIGCHLD.  This signal is supposed to be delivered to the
parent program when the child program exits.  Since this signal only
makes sense when a child program can run asynchronously with the
parent (otherwise, you always know when the child exits), it is not
supported.

> 	Is the bash code in error by trying to compile something that 
> refers to SIGCHLD when JOB_CONTROL is undefined?

It is usually a good idea to only use a signal name if it is defined,
like this:

     #ifdef SIGCLD
     ... code that uses SIGCLD ...
     #endif

However, it could be that large parts of Bash don't make sense without
SIGCLD/SIGCHLD, so the above paradigm might not be good enough.

> What shall I do to work around this: define SIGCLD/SIGCHLD with
> (somewhat arbitrary) values?  Define JOB_CONTROL and pray?

I suggest to look at the changes introduced by Daisuke Aoyama into the
port of Bash 1.14.7, and do something similar.  This port is
exceptionally well done, so it should be a good place to start your
work.