> > I actually did consider adding support for an extended form of php://fd > where one would specify the desired file descriptor: php://fd/<orig fd>/<new > fd>. It would call dup2 instead of dup. > > However, I got into some trouble on shutdown because this could cause > stdout to be closed ahead of time and then the output subsystem would cause > either a segfault or a memory leak (can't recall). I didn't spend more than > 20 minutes on this as it was not the problem I was trying to solve, so > there's probably an easy solution. If you want to work on this, extending > php://fd would likely be a good place. > > -- > Gustavo Lopes > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > thanks Gustavo. as you check my mail, I also mentioned using dup2 instead of dup, for obvious reasons. adding dup2 support for the php://fd stream would be better than the current situation, but I can't see why are we trying to force everything into that. I mean everything on the http://www.php.net/manual/en/wrappers.php can be achived through a function also. there are some case when you can save a couple of lines of code with the wrappers and with http://www.php.net/manual/en/context.http.php but there is no method for opening FDs or the dup2 that you mentioned. I think that it would be more consistent with the rest of the language, and one would more likely to find fdopen than fopen('php://fd/1'); in the documentation.
closing the stdout without reopening also caused problems for me in case of an error happens, but this shouldn't happen if you properly reopen it, so I would be interested what exactly happened there. Tyrael
