Re: streams, stderr/out and zend_fprintf ?

--- Wez Furlong <wez@thebrainroom.com> wrote: > Tips: > > Don't use zend_printf. > Do try and use the php_stream_XXX API where it makes sense. Yes, knowing where it makes sense is the trick :) > When running in a web environment, or without an ncurses interface, use > the PHP_WRITE() or php_printf() functions to generate output to send to > the browser; the output will be captured in the output buffering layer. OK, that's good to know. > From what you've described, it sounds like you don't need to use the > streams API, so you are free to use the usual stdio approach, just > beware of the limitations of the solaris libc; if you are using the > pre-opened std* streams, you will be fine; if you need to open your own, > you might run out of luck. I don't have to deal with Solaris, fortunately. However, I'm unclear as to what I've described that makes it sound like I don't need to use the streams API. Because it's primarily a CLI extension? Or because I'm talking to a serial port? > Consider using POSIX open(), read(), write() rather than stdio. If you > miss printf and fprintf, you can open a php stream around an existing > file descriptor (with no more overhead than stdio) and use > php_stream_printf(). My initial take on getting the serial device online was to use a resource, defined as (where msr is the name of the device): typedef struct { int filedes; struct termios sio; } msr_resource; Thus, also having init and destructor functions to open(), cfmakeraw(), cfsetspeed(), tcsetattr() and close() the returned filedes. Then it hit me that php.net/streams says a stream is already a resource with many of the resource housekeeping tasks taken care of. Great, but then how can I set my serial options on a php stream (like cfmakeraw, for example)? I see the ability to cast a php_stream to a filedes, but vice-versa, or as you said "you can open a php stream around an existing file descriptor," I'm having no luck? > To access the std* streams via the streams API, you can open them using > the special php://stdin, php://stdout and php://stderr filenames. This > is, of course, not always a sensible thing to do in a web environment. Ahh, just like in PHPland... thanks. Perhaps I'm making it overly complex, and simply using a resource->filedes is the way to go, but I'd like to get familiarized with php streams. Any additional tips would be helpful. Thanks Wez, Hans > > For more info, read the docs online at http://php.net/streams > > --Wez. > > > On Tue, 6 May 2003, Hans Zaunere wrote: > > > > > I'm developing an extension that talks to a serial device (under RedHat > 7.3). > > The dynamic module will then be loaded into a CLI PHP, which will use an > > ncurses interface, MySQL connectivity, etc. to make the application > complete. > > > > In light of recent talk about streams in extensions, I have a couple of > > questions (I haven't done much extension programming yet, so forgive any > > naiveness and hopefully I haven't missed anything in the mail archives): > > > > -- With most console C programs I use the builtin stdin/stdout/stderr > macros > > with functions like fprintf. As a PHP extension, should I still be using > > these, or does php_streams implement something different (ie, a > php_stderr > > macro)? > > > > -- I'm seeing there is a zend_printf() but no zend_fprintf(). Am I > missing > > something, or should I just be using the standard C lib functions? > > > > -- Should I be using php_stream_* functions to explicitly open the > standard > > I/O streams? Please say no. > > > > For the extension I'm developing now, I can see how much of this is > > irrelevant; it's a CLI based application, and when the process ends, so > will > > everything else, thanks to the kernel. However, I would like to design > the > > extension so that if I were to load it into an Apache DSO PHP, it'd be > > working "the right way" and utilize all that's modern PHP extension > > development (yes, I would have a reason to talk a serial device protocol > from > > a web server :) > > > > Any pointers on these types of best practices would be greatly > appreciated. > > > > Thank you, > > > > Hans > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > >