From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-6823-mason-zsh=primenet.com.au@sunsite.dk>
Received: (qmail 24809 invoked from network); 1 Dec 2003 06:56:25 -0000
Received: from sunsite.dk (130.225.247.90)
  by ns1.primenet.com.au with SMTP; 1 Dec 2003 06:56:25 -0000
Received: (qmail 29162 invoked by alias); 1 Dec 2003 06:56:09 -0000
Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 6823
Received: (qmail 29135 invoked from network); 1 Dec 2003 06:56:08 -0000
Received: from localhost (HELO sunsite.dk) (127.0.0.1)
  by localhost with SMTP; 1 Dec 2003 06:56:08 -0000
X-MessageWall-Score: 0 (sunsite.dk)
Received: from [4.33.218.17] by sunsite.dk (MessageWall 1.0.8) with SMTP; 1 Dec 2003 6:56:8 -0000
Received: (from schaefer@localhost)
	by candle.brasslantern.com (8.11.6/8.11.6) id hB16u6D03803
	for zsh-users@sunsite.dk; Sun, 30 Nov 2003 22:56:06 -0800
X-Authentication-Warning: candle.brasslantern.com: schaefer set sender to schaefer@closedmail.com using -f
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <1031201065606.ZM3802@candle.brasslantern.com>
Date: Mon, 1 Dec 2003 06:56:06 +0000
In-Reply-To: <87fzg5ax4d.fsf@ceramic.fifi.org>
Comments: In reply to Philippe Troin <phil@fifi.org>
        "Re: problem building zsh in background" (Nov 30, 10:08pm)
References: <m3d6bgq2tk.wl%petersen@redhat.com> 
	<87d6bgrxml.fsf@ceramic.fifi.org> 
	<m3vfp7o6c8.wl%petersen@redhat.com> 
	<877k1ngcp5.fsf@ceramic.fifi.org> 
	<m365h68uk6.wl%petersen@redhat.com> 
	<m3y8u26r3t.wl%petersen@redhat.com> 
	<87zneewgvd.fsf@ceramic.fifi.org> 
	<20031130185652.GA26891@lorien.emufarm.org> 
	<87fzg5ax4d.fsf@ceramic.fifi.org>
X-Mailer: Z-Mail (5.0.0 30July97)
To: Zsh-users <zsh-users@sunsite.dk>
Subject: Re: problem building zsh in background
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Nov 30, 10:08pm, Philippe Troin wrote:
}
} Okay, what about the following behavior:
} 
}  - keep the second patch (will fail if ran from cron or any other
}    situation where there is no ctty)
} 
}  - add a --with-working-tcsetpgrp / --without-working-tcsetpgrp switch
}    to force configure to skip the test (instead of failing) and assume
}    a working / non-working tcsetpgrp
} 
} Would that satisfy everyone?

Other than that it should just be --with-tcsetpgroup (what's the point of
"working"?  Is there a --with-broken-tcsetpgroup option?), I think that
sounds fine.