how to redirect STDOUT to a file in PHP?
the example code is redirecting OUTPUT to a file, not STDOUT, Bas’s solution solutions only appears to work because CLI (and to a lesser extend CGI) enviroments uses theses streams interchangably. apache-module PHP does not.
8 Answers 8
It is possible to write STDOUT directly to a file in PHP, which is much easier and more straightforward than using output bufferering.
Do this in the very beginning of your script:
fclose(STDIN); fclose(STDOUT); fclose(STDERR); $STDIN = fopen('/dev/null', 'r'); $STDOUT = fopen('application.log', 'wb'); $STDERR = fopen('error.log', 'wb'); Why at the very beginning you may ask? No file descriptors should be opened yet, because when you close the standard input, output and error file descriptors, the first three new descriptors will become the NEW standard input, output and error file descriptors.
In my example here I redirected standard input to /dev/null and the output and error file descriptors to log files. This is common practice when making a daemon script in PHP.
To write to the application.log file, this would suffice:
To write to the error.log, one would have to do:
fwrite($STDERR, "Something went wrong\n"); Please note that when you change the input, output and error descriptors, the build-in PHP constants STDIN, STDOUT and STDERR will be rendered unusable. PHP will not update these constants to the new descriptors and it is not allowed to redefine these constants (they are called constants for a reason after all).
It’s basic Unix behavior (that’s also why it’s not portable to windows). Unix gives the smallest file descriptor available to a file. Given that the fcloses close 0, 1 and 2, they become available for the next 3 open. Also Unix is awesome in its simplicity.
If this is being used with a cron script, you probably want to use fopen with mode a so your previous log is not overwritten.
@Pacerier, exactly. It does not matter how you name the variables. I just kept them the same as their constant equivalents for readability. The only really important thing is the order in which you close the default descriptors and open the new ones.
here’s a way to divert OUTPUT which appears to be the original problem
$ob_file = fopen('test.txt','w'); function ob_file_callback($buffer) < global $ob_file; fwrite($ob_file,$buffer); >ob_start('ob_file_callback'); If you are using PHP 5.3 or newer, I would suggest to use a closure function without the need of having $ob_file to be global: $ob_file_callback = function($buffer) use ($ob_file) < fwrite($ob_file, $buffer); >; ob_start($ob_file_callback);
None of the answers worked for my particular case where I needed a cross platform way of redirecting the output as soon as it was echo’d out so that I could follow the logs with tail -f log.txt or another log viewing app. I came up with the following solution:
$logFp = fopen('log.txt', 'w'); ob_start(function($buffer) use($logFp)< fwrite($logFp, $buffer); >, 1); //notice the use of chunk_size == 1 echo "first output\n"; sleep(10) echo "second output\n"; ob_end_clean(); I haven’t noticed any performance issues but if you do, you can change chunk_size to greater values.
Now just tail -f the log file:
» ob_start(function($buffer) use($logFp)< " Woa, could you explain this magic? Since when can one pass functions as arguments? What is this 'use' thing? Since when is this valid PHP syntax?
No, output buffering is as good as it gets. Though it’s slightly nicer to just do
ob_start(); echo 'xxx'; $contents = ob_get_flush(); file_put_contents($file,$contents); doesn’t ob_get_flush() also send the buffer contents to the browser? maybe ob_get_clean() would be better.
Using eio pecl module eio is very easy, also you can capture PHP internal errors, var_dump, echo, etc. In this code, you can found some examples of different situations.
$fdout = fopen('/tmp/stdout.log', 'wb'); $fderr = fopen('/tmp/stderr.log', 'wb'); eio_dup2($fdout, STDOUT); eio_dup2($fderr, STDERR); eio_event_loop(); fclose($fdout); fclose($fderr); // output examples echo "message to stdout\n"; $v2dump = array(10, "graphinux"); var_dump($v2dump); // php internal error/warning $div0 = 10/0; // user errors messages fwrite(STDERR, "user controlled error\n"); Call to eio_event_loop is used to be sure that previous eio requests have been processed. If you need append on log, on fopen call, use mode ‘ab’ instead of ‘wb’.
Install eio module is very easy (http://php.net/manual/es/eio.installation.php). I tested this example with version 1.2.6 of eio module.
You can install Eio extension
and duplicate a file descriptor
$temp=fopen('/tmp/my_stdout','a'); $my_data='my something'; $foo=eio_dup2($temp,STDOUT,EIO_PRI_MAX,function($data,$esult,$request)< var_dump($data,$esult,$request); var_dump(eio_get_last_error($request)); >,$my_data); eio_event_loop(); echo "something to stdout\n"; fclose($temp); this creates new file descriptor and rewrites target stream of STDOUT
this can be done with STDERR as well
and constants STD[OUT|ERR] are still usable
I understand that this question is ancient, but people trying to do what this question asks will likely end up here. Both of you.
If you are running under a particular environment.
- Running under Linux (probably most other Unix like operating systems, untested)
- Running via CLI (Untested on web servers)
You can actually close all of your file descriptors (yes all, which means it’s probably best to do this at the very beginning of execution. for example just after a pcntl_fork() call to background the process in a daemon (which seems like the most common need for something like this)
fclose( STDIN ); // fd 3 fclose( STDERR); // fd 2 fclose( STDOUT ); // fd 1 And then re-open the file descriptors, assigning them to a variable that will not fall out of scope and thus be garbage collected. Because Linux will predictably open them in the proper order.
$kept_in_scope_variable_fd1 = fopen(. ); // fd 1 $kept_in_scope_variable_fd2 = fopen(. ); // fd 2 $kept_in_scope_variable_fd3 = fopen( '/dev/null', . ); // fd 3 You can use whatever files or devices you want for this. I gave /dev/null as the example for STDIN (fd3) because that’s probably the most common case for this kind of code.
Once this is done you should be able to do normal things like echo , print_r , var_dump , etc without specifically needing to write to a file with a function. Which is useful when you’re trying to background code that you do not want to, or aren’t able to, rewrite to be file-pointer-output-friendly.
YMMV for other environments and things like having other FD’s open, etc. My advice is to start with a small test script to prove that it works, or doesn’t, in your environment and then move on to integration from there.
Output file with php
php:// — Accessing various I/O streams
Description
PHP provides a number of miscellaneous I/O streams that allow access to PHP’s own input and output streams, the standard input, output and error file descriptors, in-memory and disk-backed temporary file streams, and filters that can manipulate other file resources as they are read from and written to.
php://stdin, php://stdout and php://stderr
php://stdin , php://stdout and php://stderr allow direct access to the corresponding input or output stream of the PHP process. The stream references a duplicate file descriptor, so if you open php://stdin and later close it, you close only your copy of the descriptor-the actual stream referenced by STDIN is unaffected. It is recommended that you simply use the constants STDIN , STDOUT and STDERR instead of manually opening streams using these wrappers.
php://stdin is read-only, whereas php://stdout and php://stderr are write-only.
php://input
php://input is a read-only stream that allows you to read raw data from the request body. php://input is not available in POST requests with enctype=»multipart/form-data» if enable_post_data_reading option is enabled.
php://output
php://output is a write-only stream that allows you to write to the output buffer mechanism in the same way as print and echo .
php://fd
php://fd allows direct access to the given file descriptor. For example, php://fd/3 refers to file descriptor 3.
php://memory and php://temp
php://memory and php://temp are read-write streams that allow temporary data to be stored in a file-like wrapper. The only difference between the two is that php://memory will always store its data in memory, whereas php://temp will use a temporary file once the amount of data stored hits a predefined limit (the default is 2 MB). The location of this temporary file is determined in the same way as the sys_get_temp_dir() function.
The memory limit of php://temp can be controlled by appending /maxmemory:NN , where NN is the maximum amount of data to keep in memory before using a temporary file, in bytes.
php://filter
php://filter is a kind of meta-wrapper designed to permit the application of filters to a stream at the time of opening. This is useful with all-in-one file functions such as readfile() , file() , and file_get_contents() where there is otherwise no opportunity to apply a filter to the stream prior the contents being read.
The php://filter target takes the following parameters as part of its path. Multiple filter chains can be specified on one path. Please refer to the examples for specifics on using these parameters.
| Name | Description |
|---|---|
| resource= | This parameter is required. It specifies the stream that you would like to filter. |
| read= | This parameter is optional. One or more filter names can be provided here, separated by the pipe character ( | ). |
| write= | This parameter is optional. One or more filter names can be provided here, separated by the pipe character ( | ). |
| Any filter lists which are not prefixed by read= or write= will be applied to both the read and write chains as appropriate. |
Options
| Attribute | Supported |
|---|---|
| Restricted by allow_url_fopen | No |
| Restricted by allow_url_include | php://input , php://stdin , php://memory and php://temp only. |
| Allows Reading | php://stdin , php://input , php://fd , php://memory and php://temp only. |
| Allows Writing | php://stdout , php://stderr , php://output , php://fd , php://memory and php://temp only. |
| Allows Appending | php://stdout , php://stderr , php://output , php://fd , php://memory and php://temp only. (Equivalent to writing) |
| Allows Simultaneous Reading and Writing | php://fd , php://memory and php://temp only. |
| Supports stat() | No. However, php://memory and php://temp support fstat() . |
| Supports unlink() | No |
| Supports rename() | No |
| Supports mkdir() | No |
| Supports rmdir() | No |
| Supports stream_select() | php://stdin , php://stdout , php://stderr , php://fd and php://temp only. |
Examples
Example #1 php://temp/maxmemory
This optional parameter allows setting the memory limit before php://temp starts using a temporary file.
// Set the limit to 5 MB.
$fiveMBs = 5 * 1024 * 1024 ;
$fp = fopen ( «php://temp/maxmemory: $fiveMBs » , ‘r+’ );
// Read what we have written.
rewind ( $fp );
echo stream_get_contents ( $fp );
?>
Example #2 php://filter/resource=
This parameter must be located at the end of your php://filter specification and should point to the stream which you want filtered.
/* This is equivalent to simply:
readfile(«http://www.example.com»);
since no filters are actually specified */
Example #3 php://filter/read=
This parameter takes one or more filternames separated by the pipe character | .
/* This will output the contents of
www.example.com entirely in uppercase */
readfile ( «php://filter/read=string.toupper/resource=http://www.example.com» );
/* This will do the same as above
but will also ROT13 encode it */
readfile ( «php://filter/read=string.toupper|string.rot13/resource=http://www.example.com» );
?>
Example #4 php://filter/write=
This parameter takes one or more filternames separated by the pipe character | .
/* This will filter the string «Hello World»
through the rot13 filter, then write to
example.txt in the current directory */
file_put_contents ( «php://filter/write=string.rot13/resource=example.txt» , «Hello World» );
?>
Example #5 php://memory and php://temp are not reusable
php://memory and php://temp are not reusable, i.e. after the streams have been closed there is no way to refer to them again.