Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9650
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <40975865.6000706@wormus.com>
Date: Tue, 04 May 2004 09:46:29 +0100
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
MIME-Version: 1.0
To: internals@lists.php.net
Content-Type: multipart/mixed;
 boundary="------------040207030905080400060808"
Subject: PHP -R STDIN chomping line ends
From: aaron@wormus.com (Aaron Wormus)

--------------040207030905080400060808
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Greetings!
	I've been exploring the work done on the PHP CLI sapi, and am impressed 
with the new features that are in PHP 5.

	One thing that I am a bit troubled about is the behaviour of the -R 
switch in that it removes the trailing \n and \r line end characters 
when it delivers the line to $argn. I can't see any useful reasons for 
it doing this, and it does not handle STDIN the way it should.

	The following file should just pass through the following code, not 
strip out all the line ends:

cat file.txt | php -R 'echo "$argn";'

	I realize that one possible reason that this was included was because 
it is simpler to add a line end if needed then to chomp it. However, 
even if I do use:

cat file.txt | php -R 'echo "$argn\n";'

if the file uses \r\n line ends, it still changes the file. And it's 
unacceptable to have to know what type of file it is when doing a 
command as simple as that.

	Curt Zirzow provided me with the patch that I'm including, and would 
like to ask that the behaviour be changed before the PHP 5 final.

	I realize that this has been working like this for over a year, and by 
making this change we would be breaking backwards compatibility (with 
pre version 5 releases). However, since I do believe that this behaviour 
is wrong, I feel that it would be a mistake to let it get into the PHP 5 
final, as it will need to get changed sooner or later, and if it is 
introduced into PHP with version 5 then it will be much harder to reverse.

	I'm sorry if I'm ranting a bit. I am known to miss obvious things, so 
if it's my mistake and there is a good reason for the behaviour, please 
let me know. I appreciate all the work that has gone into PHP 5, I'm 
enjoying it throughly!
	
Aaron

--------------040207030905080400060808
Content-Type: text/plain;
 name="php_cli.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="php_cli.patch"

Index: php_cli.c
===================================================================
RCS file: /repository/php-src/sapi/cli/php_cli.c,v
retrieving revision 1.112
diff -u -r1.112 php_cli.c
--- php_cli.c	4 Mar 2004 22:53:09 -0000	1.112
+++ php_cli.c	3 May 2004 18:15:40 -0000
@@ -1002,12 +1002,9 @@
 				zend_hash_update(&EG(symbol_table), "argi", sizeof("argi"), &argi, sizeof(pval *), NULL);
 				while (exit_status == SUCCESS && (input=php_stream_gets(s_in_process, NULL, 0)) != NULL) {
 					len = strlen(input);
-					while (len-- && (input[len]=='\n' || input[len]=='\r')) {
-						input[len] = '\0';
-					}
 					ALLOC_ZVAL(argn);
 					Z_TYPE_P(argn) = IS_STRING;
-					Z_STRLEN_P(argn) = ++len;
+					Z_STRLEN_P(argn) = len;
 					Z_STRVAL_P(argn) = estrndup(input, len);
 					INIT_PZVAL(argn);
 					zend_hash_update(&EG(symbol_table), "argn", sizeof("argn"), &argn, sizeof(pval *), NULL);

--------------040207030905080400060808--