Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Any comment on file descriptor behavior in functions?
- X-seq: zsh-workers 21073
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: Any comment on file descriptor behavior in functions?
- Date: Thu, 31 Mar 2005 09:52:30 +0100
- In-reply-to: <1050326170515.ZM19503@xxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <1050321002236.ZM10916@xxxxxxxxxxxxxxxxxxxxxxx> <200503221404.j2ME41EL009572@xxxxxxxxxxxxxx> <1050322171125.ZM13668@xxxxxxxxxxxxxxxxxxxxxxx> <200503221831.j2MIVI09014962@xxxxxxxxxxxxxx> <1050326170515.ZM19503@xxxxxxxxxxxxxxxxxxxxxxx>
Bart Schaefer wrote:
> } As far as I can see, when entering a function the values for process
> } subsitutions would be incremented so that both types would be closed for
> } an external program, but on a nested function they'd both be incremented
> } further so they wouldn't.
>
> Yes, I concur. What I can't figure out is why they need to be incremented
> at all? Why not just assign them the do-not-close value to begin with?
> Something having to do with them persisting for only one command?
I think it's to do with the way they're closed. There's no way of
knowing whether they're attached to the command currently passing
through execcmd() or to some shell structure that's calling a command at
a lower level, so there's the risk of a file descriptor being closed too
early.
A more rational way to do this might be to have a list of file
descriptors to close in the job structure, like the existing "filelist"
of temporary files to be deleted.
I'll commit my patch.
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
**********************************************************************
Messages sorted by:
Reverse Date,
Date,
Thread,
Author