On Sat, May 7, 2011 at 1:40 AM, Ferenc Kovacs <i...@tyrael.hu> wrote: > On Thu, May 5, 2011 at 2:30 AM, Ferenc Kovacs <i...@tyrael.hu> wrote: >> >> >> On Sat, Apr 30, 2011 at 5:23 PM, Ferenc Kovacs <i...@tyrael.hu> wrote: >>>> >>>> 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 >> >> I put together the fileno, fdopen, dup2, fclose stuff as a pecl >> extension(called fildes), the sourcecode available here: >> https://github.com/Tyrael/php-fildes >> with this, you can do something like this: >> <?php >> $stdout_fd_orig = fildes_fileno(STDOUT); >> fclose(STDOUT); >> $stdout = fopen("out.log", "a"); >> $fd_tmp = fildes_fileno($stdout); >> $stdout_fd = fildes_dup2($fd_tmp, $stdout_fd_orig); >> if($stdout_fd != $fd_tmp){ >> fildes_close($fd_tmp); >> } >> echo "Hello world!"; // this goes to out.log >> I'm really a novice in C, so any feedback welcome. >> particularly >> here https://github.com/Tyrael/php-fildes/blob/master/fildes.c#L211 >> Tyrael > > as somebody pointed out, the example could be simplified as: > <?php > $stdout = fopen("out.log", "a"); > $tmp_fd = fildes_fileno($stdout); > if($tmp_fd, fildes_fileno(STDOUT))<0){ > fwrite(STDERR, "dup2 failed"); > exit; > } > fildes_close($tmp_fd); > echo "Hello world!"; // this goes to out.log > > Could somebody review the source? as I mentioned in my previous email > I had some problem here: > https://github.com/Tyrael/php-fildes/blob/master/fildes.c#L211 > > if I define the second argument as int, the first argument will be always 0. > I have no idea whats going there. > > Tyrael >
and I forgot to ask the most important thing: what do you think about the feature itself? I would really like to have it in the core, but I think it would be better to have this as functions, than adding more stream magic. I'm not sure where would this functions fit the best. 1, it could be added to the filesystem functions (we already have some which are only supported on some systems) 2, it could be added to the posix functions (would be logical) 3, it could be added as stream stuff (Gustavo supports this imo) 4, it could be added to the dio pecl extension (could fit in there, but it's not in the core, and the package doesn't seem much alive) 5, it could be added to pecl as a different extension (bad idea, imo) so, what do you think? Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
