#48803 [Tbd->Asn]: fprintf(STDOUT, ...) and printf(...) behave differently and affect STDERR

From: Date: Sat, 16 Jan 2010 22:18:49 +0000
Subject: #48803 [Tbd->Asn]: fprintf(STDOUT, ...) and printf(...) behave differently and affect STDERR
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-3721@lists.php.net to get a copy of this message
ID: 48803 Updated by: bjori@php.net Reported By: andrey dot vihrov at gmail dot com -Status: To be documented +Status: Assigned Bug Type: Documentation problem Operating System: Gentoo Linux amd64 PHP Version: 5.*, 6CVS (2009-07-06) -Assigned To: +Assigned To: jani New Comment: I don't have the slightest idea what is expected to be documented here. Could you please explain (preferably with a copy&pasteable example) what should be documented? Previous Comments: ------------------------------------------------------------------------ [2009-07-07 12:59:20] jani@php.net Actually this is by design. Since PHP is meant primarily for web usage, such "weird" things are necessary like using ignore_user_abort(true); to get full "power" for console scripts. This should be mentioned in relevant parts in documentation. printf() mainly since that is especially tricky if you don't know things works under the hood. ------------------------------------------------------------------------ [2009-07-06 13:00:58] jani@php.net As a workaround, just set 'ignore_user_abort=1' in your CLI ini. ------------------------------------------------------------------------ [2009-07-06 11:58:07] andrey dot vihrov at gmail dot com Hi, thanks for the explanation. Quite simply errors can occur when writing to any real media (leaving the terminal aside). For a simple example, consider a PHP script that is being started with its output being redirected to a file. If the target filesystem, e. g., runs out of space or encounters an I/O error (like network fs being disconnected), the script will want to exit unsuccessfully and, optionally, inform the user about it using STDERR. If this is not the case, the user will assume things went good, which does not correspond to reality and may lead to further failures. The example provided in previous comment is the classical one to check if software handles I/O errors correctly, so I used it for demonstration. ------------------------------------------------------------------------ [2009-07-05 11:20:37] sjoerd-php at linuxonly dot nl Thank you for your bug report. The problem is not that STDERR is affected, but that the script is terminated immediately. Furthermore, it is not specific for printf. time php -r 'echo 'a'; sleep(5);' > /dev/full Expected: real 0m5.030s Actual: real 0m0.030s Your contrived example writes to /dev/full, which obviously fails. Do you have a more real-life example where writing to STDOUT fails? ------------------------------------------------------------------------ [2009-07-05 10:25:31] andrey dot vihrov at gmail dot com Description: ------------ These functions behave differently if the underlying I/O operation on STDOUT fails. The difference is that STDERR is affected in one case. Configure Command => './configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64' '--with-pcre-regex=/usr' '--enable-cli' '--disable-cgi' '--with-config-file-path=/etc/php/cli-php5' '--with-config-file-scan-dir=/etc/php/cli-php5/ext-active' '--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar' '--disable-ctype' '--without-curl' '--without-curlwrappers' '--disable-dbase' '--enable-exif' '--without-fbsql' '--without-fdftk' '--disable-filter' '--disable-ftp' '--with-gettext' '--without-gmp' '--disable-hash' '--disable-ipv6' '--disable-json' '--without-kerberos' '--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql' '--without-mssql' '--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--disable-pdo' '--without-pgsql' '--disable-posix' '--with-pspell' '--without-recode' '--disable-simplexml' '--disable-shmop' '--without-snmp' '--disable-soap' '--disable-sockets' '--without-sybase' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--without-tidy' '--disable-tokenizer' '--disable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--without-xsl' '--disable-zip' '--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb' '--with-db4' '--disable-flatfile' '--with-gdbm' '--disable-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--without-xpm-dir' '--with-gd' '--without-mysqli' '--with-readline' '--without-libedit' '--without-mm' '--with-sqlite=/usr' '--enable-sqlite-utf8' > diff php.ini-dist /etc/php/cli-php5/php.ini 474c474 < ;include_path = ".:/php/includes" --- > include_path = ".:/usr/share/php5:/usr/share/php" 491c491 < extension_dir = "./" --- > extension_dir = /usr/lib64/php5/lib/php/extensions/no-debug-non-zts-20060613 560c560 < allow_url_fopen = On --- > allow_url_fopen = Off 1283a1284,1288 > > ; MySQL extensions default connection charset settings > ;mysql.connect_charset = utf8 > ;mysqli.connect_charset = utf8 > ;pdo_mysql.connect_charset = utf8 Reproduce code: --------------- Script #1 #! /usr/bin/php <? fprintf(STDOUT, "stdout\n"); fprintf(STDERR, "stderr\n"); ?> Testcase #2 #! /usr/bin/php <? printf("stdout\n"); fprintf(STDERR, "stderr\n"); ?> Expected result: ---------------- > ./test1.php > /dev/full stderr > ./test2.php > /dev/full stderr > Actual result: -------------- > ./test1.php > /dev/full stderr > ./test2.php > /dev/full > ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=48803&edit=1

« previous php.doc.bugs (#3721) next »