On Sun, Feb 09, 2003 at 08:05:14PM -, Ilia Alshanetsky wrote :
iliaa Sun Feb 9 15:05:14 2003 EDT
Modified files:
/php4/ext/standardfile.c
Log:
Added feature request #14097 (option allowing file() command not to include
line endings in it's
On Mon, 10 Feb 2003, Markus Fischer wrote:
On Sun, Feb 09, 2003 at 08:05:14PM -, Ilia Alshanetsky wrote :
iliaa Sun Feb 9 15:05:14 2003 EDT
Modified files:
/php4/ext/standard file.c
Log:
Added feature request #14097 (option allowing
On February 10, 2003 03:34 am, you wrote:
On Sun, Feb 09, 2003 at 08:05:14PM -, Ilia Alshanetsky wrote :
iliaa Sun Feb 9 15:05:14 2003 EDT
Modified files:
/php4/ext/standard file.c
Log:
Added feature request #14097 (option allowing file() command not
On Mon, 10 Feb 2003, Ilia A. wrote:
We could turn the existing one into a flags parameter:
1 - use include path
2 - include new line
4 - skip_blank_lines
This would not break BC and we don't need multiple optional
parameters.
Do we want to create
Attached is the proposed solution.
Ilia
Index: ext/standard/file.c
===
RCS file: /repository/php4/ext/standard/file.c,v
retrieving revision 1.299
diff -u -3 -p -r1.299 file.c
--- ext/standard/file.c 9 Feb 2003 20:43:05 -
Hey Ilia,
Lets also have either an enum or some real #define'd constants for the
values used in the C code.
eg:
REGISTER_LONG_CONSTANT() and the code that checks for a number should
both be using a symbolic constant rather than a hard-coded number.
--Wez.
On Mon, 10 Feb 2003, Ilia A. wrote:
Here is the final revision of the patch.
Ilia
Index: ext/standard/file.c
===
RCS file: /repository/php4/ext/standard/file.c,v
retrieving revision 1.300
diff -u -3 -p -r1.300 file.c
--- ext/standard/file.c 9 Feb 2003 23:11:23 -
Should we have stat also for memory/temp streams? should be no problem but
supporting access/modified time with it would slow down performance as querying
time is timeconsumpting on most systems.
marcus
At 01:49 28.03.2002, you wrote:
wez Wed Mar 27 19:49:00 2002 EDT
Modified
I was just about to do an automatic merge of this fix to the PHP_4_0_6
branch when I saw that the merge will also merge the stat() update which
creates associative keys too (cvs update -j 1.159 file.c after an update -r
PHP_4_0_6).
Any objections to me merging that one too? I think it would be
On Fri, 18 May 2001, Andi Gutmans wrote:
I was just about to do an automatic merge of this fix to the PHP_4_0_6
branch when I saw that the merge will also merge the stat() update which
creates associative keys too (cvs update -j 1.159 file.c after an update -r
PHP_4_0_6).
Any objections to
I am all for that, but don't forget filestat.c and the macro
in php_filestat.h.
Thanks,
Jason
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 18, 2001 3:08 PM
Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard file.c
I
At 05:00 PM 5/18/2001 -0500, Jason Greene wrote:
I am all for that, but don't forget filestat.c and the macro
in php_filestat.h.
Hmm, that's making me think twice now. Maybe we should just merge Sascha's
fixes.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail:
At 12:04 AM 5/19/2001 +0200, Sascha Schumann wrote:
On Fri, 18 May 2001, Andi Gutmans wrote:
I was just about to do an automatic merge of this fix to the PHP_4_0_6
branch when I saw that the merge will also merge the stat() update which
creates associative keys too (cvs update -j 1.159
I agree, though it would be nice to release this soon, however, it is not worth
risking the RP.
-Jason
From: Andi Gutmans [EMAIL PROTECTED]
Date: 2001/05/18 Fri PM 06:26:49 CDT
To: Jason Greene [EMAIL PROTECTED],[EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext
Well, I was trying to fix one bug, not introduce others. If you read the
documentation for get_meta_tags you will see that it returns an associative
array that is keyed by the value of the NAME attribute while the value is
the data within the CONTENT attribute.
If other members of the
15 matches
Mail list logo
