> > 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.phpbut >>>>> 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. >>>>> >>>> > I just don't see the point of duplicating functionality, especially when > there's already a closely related wrapper. > > It's not true that everything in http://php.net/wrappers can can be done > in another fashion. In fact, for the php:// wrappers, which is what we're > talking about, ONLY ONE (php://filter) duplicates functionality that can be > achieved with functions. > > you are right, not everything, but many of them is either have alternative in core, or had it through pecl when that stream was introduced AFAIK .
> > 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. >>>>> >>>> > Yes, this causes a memory leak. Maybe that was the problem I found. Duping > the file descriptor after the call to dup2 would solve this, which I think > is one more reason not to expose these low-level functions directly and > provide a safer alternative (more below). > this is why I think that it would be better to provide a way to redirect/reopen the STDIN/STDOUT/STDERR. currently one can only close them, which could cause problmes, if something directly or indirectly tries to use one of those fps. > > >>>> 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 >>>> [...] >>>> >>> 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. >>> >>> > See http://lxr.php.net/xref/PHP_TRUNK/README.PARAMETER_PARSING_API#72 > > okay, I read that before, but somehow I belived that I should use ints because the C functions use its for fds. I will update that. > > 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) >> >> > PHP tries to abstract away these kind of details; I don't think direct > access to low level I/O functions is appropriate in the core. The dio pecl > extension would seem more appropriate. I don't know how alive it is, but if > I recall correctly, it got a new maintainer last year. > > The POSIX extension would also seem to make sense, but it seems more > focused on another class of functions and is not available on Windows. > > That said, if some useful use case is not available (or is available, but > it's awkward) in PHP, we should try to fix it. If I understand correctly, > what compels you is being able to replace stdin, stdout and stderr. > I would tend to support #3; for reference here goes the change to php://fd > that would be necessary. The problem is, as far as I know, there's no way to > retrieve the file descriptor associated a stream, so we'd still have to rely > on opening order. > > One possible solution would be to add this information to the wrapper data > of the "plain files" and in systems other than Windows, to other relevant > stream types (e.g. sockets). I think your solution of calling stream_cast is > a good option because in Windows the socket streams return socket handles -- > file descriptors are an abstraction in the C lib, not really part of the > windows API -- and because in some stream implementations that call has > important side effects. > > Another option would option would be to unburden the user from dealing with > file descriptors completely and provide a function to replace the standard > file descriptors with a stream. > I agree, I think that the best solution would be to - add support for replacing a stream with another (a similar function for http://php.net/manual/en/function.stream-copy-to-stream.php<http://hu2.php.net/manual/en/function.stream-copy-to-stream.php> or maybe extending that), which would be available on all platforms, this would cover my initial use-case. - I think we should also provide the fileno functionality, because without that, the php://fd is pretty useless. - anything else, like dup2, fcntl should go to the dio or posix extension, that would be useful for some people. what do you think? Tyrael
