From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-29563-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 16047 invoked by alias); 19 Jul 2011 14:28:33 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 29563
Received: (qmail 7840 invoked from network); 19 Jul 2011 14:28:28 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	autolearn=ham version=3.3.1
Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts)
From: Bart Schaefer <schaefer@brasslantern.com>
Message-id: <110719072802.ZM15172@torch.brasslantern.com>
Date: Tue, 19 Jul 2011 07:28:01 -0700
In-reply-to: <20110719105223.14e571c3@pwslap01u.europe.root.pri>
Comments: In reply to Peter Stephenson <Peter.Stephenson@csr.com>
 "Re: Zsh 4.3.12: subshell in midnight commander:  precmd: 15: bad file
 descriptor" (Jul 19, 10:52am)
References: <alpine.DEB.2.00.1107181000170.11852@ipnp.troja.mff.cuni.cz>
	<20110718100718.56865117@pwslap01u.europe.root.pri>
	<alpine.DEB.2.00.1107181204010.21799@ipnp.troja.mff.cuni.cz>
	<110718074551.ZM13628@torch.brasslantern.com>
	<20110718162435.4c6598e8@pwslap01u.europe.root.pri>
	<110718085234.ZM13898@torch.brasslantern.com>
	<20110719105223.14e571c3@pwslap01u.europe.root.pri>
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
To: <zsh-workers@zsh.org>
Subject: Re: Zsh 4.3.12: subshell in midnight commander:  precmd: 15: bad file
 descriptor
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii

On Jul 19, 10:52am, Peter Stephenson wrote:
} Subject: Re: Zsh 4.3.12: subshell in midnight commander:  precmd: 15: bad 
}
} On Mon, 18 Jul 2011 08:52:34 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > I wonder if the underlying problem doesn't somehow stem from this:
} > 
} >       * 27721: Src/compat.c [with unnecessary test removed], Src/exec.c,
} >       Src/system.h, Src/utils.c:  update zopenmax() not to examine huge
} >       numbers of file descriptors; only call it at initialisation;
} >       rationalise use of fdtable_size and expansion of fdtable.
} 
} I skipped over this yesterday, but are you suggesting we call zopenmax()
} with a larger limit when the user tries to manipulate an fd we don't
} know about?

I was suggesting a cause rather than any specific solution; i.e., if the
old slow zopenmax() discovered descriptors which the new one does not,
then that might explain the change in behavior; and if so, then making
some sort of change to zopenmax() might head off other cases we haven't
found yet where the code assumes zopenmax() to be comprehensive.

If you think as of 29561 that you've caught them all, then that'll do.