Re: Any comment on file descriptor behavior in functions?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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