From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19422 invoked from network); 1 Dec 2003 06:08:46 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 1 Dec 2003 06:08:46 -0000 Received: (qmail 13386 invoked by alias); 1 Dec 2003 06:08:28 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6822 Received: (qmail 13356 invoked from network); 1 Dec 2003 06:08:27 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 1 Dec 2003 06:08:27 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [216.27.190.146] by sunsite.dk (MessageWall 1.0.8) with SMTP; 1 Dec 2003 6:8:27 -0000 Received: from ceramic.fifi.org (mail@ceramic.fifi.org [216.27.190.147]) by tantale.fifi.org (8.9.3p2/8.9.3/Debian 8.9.3-21) with ESMTP id WAA15737; Sun, 30 Nov 2003 22:08:19 -0800 Received: from phil by ceramic.fifi.org with local (Exim 4.22) id 1AQhEI-0005r8-P9; Sun, 30 Nov 2003 22:08:18 -0800 To: Danek Duvall Cc: Jens Petersen , Zsh-users Subject: Re: problem building zsh in background References: <87d6bgrxml.fsf@ceramic.fifi.org> <877k1ngcp5.fsf@ceramic.fifi.org> <87zneewgvd.fsf@ceramic.fifi.org> <20031130185652.GA26891@lorien.emufarm.org> Mail-Copies-To: nobody From: Philippe Troin Date: 30 Nov 2003 22:08:18 -0800 In-Reply-To: <20031130185652.GA26891@lorien.emufarm.org> Message-ID: <87fzg5ax4d.fsf@ceramic.fifi.org> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Philippe Troin Danek Duvall writes: > On Sat, Nov 29, 2003 at 09:43:50PM -0800, Philippe Troin wrote: > > > Why do you want to run configure with nohup? > > In my case, it's more likely that I'd want to run configure from a cron > script -- nightly builds. > > > I guess I could run the test in a separate, created pty, but that is > > going to be messy to do portably in configure. > > Maybe a configure flag that forces tcsetpgrp() to be recognized as > working, and skip the test? I know that it works properly on my > platform, so I could use the flag and not worry about whether the build > will hang or abort because of the test ... 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? Phil.