From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: Re: Any comment on file descriptor behavior in functions?
Date: Sat, 26 Mar 2005 17:05:15 +0000 [thread overview]
Message-ID: <1050326170515.ZM19503@candle.brasslantern.com> (raw)
In-Reply-To: <200503221831.j2MIVI09014962@news01.csr.com>
Finally got a chance to apply this patch and try it. Looks good.
On Mar 22, 6:31pm, Peter Stephenson wrote:
}
} Bart Schaefer wrote:
} > That's not it, or rather it's too much of it. That also leaves open the
} > xtrace output descriptor, etc. The fix needs to be more specific.
}
} (I can't see any evidence for ", etc.", but I presume you just didn't
} perform an exhaustive search.)
Correct; I'm sorry.
} 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?
Appended is a suggested test entry. While writing this, I noticed that
the first process substitution test relies on the 'cut' and 'paste'
external commands. I guess there's never been a problem with that, but
I wasn't aware they were both supported on all platforms where zsh has
been compiled.
Index: Test/D03procsubst.ztst
===================================================================
retrieving revision 1.3
diff -c -r1.3 D03procsubst.ztst
--- Test/D03procsubst.ztst 23 Sep 2003 15:27:17 -0000 1.3
+++ Test/D03procsubst.ztst 26 Mar 2005 17:02:51 -0000
@@ -12,6 +12,8 @@
true
fi
+ function copycat { cat "$@" }
+
%test
paste <(cut -f1 FILE1) <(cut -f3 FILE2)
0:<(...) substitution
@@ -29,3 +31,8 @@
>< First Second Third Fourth
>---
>> Erste Zweite Dritte Vierte
+
+ copycat <(print First) <(print Zweite)
+0:FDs remain open for external commands called from functions
+>First
+>Zweite
next prev parent reply other threads:[~2005-03-26 17:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-21 0:22 Bart Schaefer
2005-03-21 11:17 ` Peter Stephenson
2005-03-22 14:04 ` Peter Stephenson
2005-03-22 17:11 ` Bart Schaefer
2005-03-22 18:31 ` Peter Stephenson
2005-03-26 17:05 ` Bart Schaefer [this message]
2005-03-31 8:52 ` Peter Stephenson
2005-03-22 18:31 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1050326170515.ZM19503@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).