Re: [PHP-DEV] [RFC] Starting 5.3
Wez Furlong wrote: On 5/7/07, Lester Caine [EMAIL PROTECTED] wrote: No one has time to work on the Firebird PDO driver because we still need the main driver to provide the functions PDO does not support. Umm, no. Nobody has time for firebird because nobody uses it. I ask people about Firebird at each conference and I've never had more than about 1 in 50 people admit to ever having used it, and those are shaky hands going up--we're not talking die-hard firebird users here. From my experience Firebird users are quite regionally distributed across Brazil and Russia. But anyways, the problem is of course not that we are uninterested in Firebird, but simply that nobody with the C hacker skills has taken this over yet. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Unicode extension in PHP6
Hi Rangel, for PHP 6 the basic string type ist unicode string and most functions will accept these as primary type. But there are a few exceptions where unicode, for different reason, makes no sense. There you have to pass a binary string - an example is the mentioned urlencode(): It has to work on bytes to be reliable but it has no clue on the proper encoding so you need to tell that function Yes the, I know about the meaning, just take this byte sequence. A good thing would be to check the archives where most reasons were posted before. johannes On Tue, 2007-05-22 at 15:16 -0300, Rangel Reale wrote: I'm also having problems with this bstring incompatibility with older versions, I know I shouldn't need to have binary strings, but the problem is, the PHP funcions does not accept an Unicode string (urlencode), so it gives me a warning. In the future will 100% of the functions accept an unicode string? If so, then to me this should not be a problem. - Original Message - From: Tomas Kuliavas [EMAIL PROTECTED] To: Jared Williams [EMAIL PROTECTED] Cc: internals@lists.php.net Sent: Tuesday, May 22, 2007 2:52 PM Subject: RE: [PHP-DEV] PHP Unicode extension in PHP6 Recent versions of PHP5, has a binary string introducer. echo strlen(b\xC4\x85); I have already said to Stefan. It is not an option. I need backwards compatibility. If older PHP versions fail with E_PARSE errors, I can't use it. I can't maintain two different library versions, because issue affect lots of functions. Currently I can only stop script execution, if unicode.semantics=on is detected. Main complain is the fact that scripts can't control mbstring.func_overload and unicode.semantics. Only script writters know, if their code depends on overloading or unicode syntax. End users might be unable to change settings in PHP_INI_PERDIR. Thanks to all for feedback. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 15/5/2007 10:47 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Wez Furlong wrote: On 5/7/07, Lester Caine [EMAIL PROTECTED] wrote: No one has time to work on the Firebird PDO driver because we still need the main driver to provide the functions PDO does not support. Umm, no. Nobody has time for firebird because nobody uses it. I ask people about Firebird at each conference and I've never had more than about 1 in 50 people admit to ever having used it, and those are shaky hands going up--we're not talking die-hard firebird users here. As for PDO missing pieces for Firebird, that's also untrue. Perhaps you don't understand the PDO architecture, but PDO was designed by taking into account every database client API; it has hooks to cater for just about every conceivable way of passing data into and out of a database API. It's the firebird driver that needs work. No Wez - As far as I am concerned I need to load the non PDO driver for those areas that PDO does not support. As well as the PDO driver for the data based stuff *IF* I wanted to go down that route. But at present there is no good reason to switch. User security, Event management, Services interface functions are not data based and while some of those functions are being moved into the Firebird SQL, things like Events can not go that route. Now you may think that everything at the database end should be controlled via SQL, and that is probably the case, but as we have discussed long ago, *WE* still need ADOdb to provide the SQL abstraction so there is little incentive to work on PDO/Firebird/ADOdb when the current Firebird/ADOdb combination is fine and are currently working ( and ADOdbLite is the 'compact' version ). While ADOdb does support PDO, the best performance is still obtained with the raw drivers for each engine. If we are NOT working with multiple engines, then we work with the raw driver so again there is little need to spend scarce time replacing something that is working and has more facilities. So until you provide a very good reason why we need to change - it's not going to happen. BLOB and parameter handling in the raw Firebird driver are a lot more flexible and simply sending a query with an optional array of parameters is much easier than HAVING to prepare everything - especially when the engine will cache things automatically anyway. PDO simply changes the ground rules without solving any particular problem as has been said all along. Now you may well convince people that all the native drivers should be dropped from PHP and only PDO supplied but I hope that does not happen and that we have a PROPER debate on an abstract database layer. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 Preview
Wez Furlong wrote: On 5/21/07, Lester Caine [EMAIL PROTECTED] wrote: Add shitting 'Vista' to the equation and customers expecting THAT to actually work . I'm not sure if you meant shipping or adding Vista to a shit list. :) Replace 'shitting' with other less polite terms ;) The only reason vista exists is to tighten M$'s hold on DRM - something that has no place in ANY modern office environment, so we DO need a real operating system that does not provide all the multimedia crap when all the machine needs to do is work like a good old fashioned typewriter. Having to go out to sites to fix things that are only broken because of the multimedia crap is getting pigging annoying :( -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Lester Caine wrote: PDO simply changes the ground rules without solving any particular problem as has been said all along. Now you may well convince people that all the native drivers should be dropped from PHP and only PDO supplied but I hope that does not happen and that we have a PROPER debate on an abstract database layer. One of the dream features back in the early days of PDO was a way to get a native extension connection out of PDO. Unfortunately this turned out to be impossible(?) to do :( regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Wez, one is doing this: stream-orig_path = estrdup(opened_path); the other something else: stream-open_filename = __zend_orig_filename ? __zend_orig_filename : __zend_filename; stream-open_lineno = __zend_orig_lineno ? __zend_orig_lineno : __zend_lineno; best regards marcus Wednesday, May 23, 2007, 6:38:59 AM, you wrote: On 5/4/07, Marcus Boerger [EMAIL PROTECTED] wrote: 2) Add open_filename debug info to streams What is this feature and how is it different from stream-orig_path that has been around for several releases? --Wez. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Unicode extension in PHP6
On 23/05/07, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi Rangel, for PHP 6 the basic string type ist unicode string and most functions will accept these as primary type. But there are a few exceptions where unicode, for different reason, makes no sense. There you have to pass a binary string - an example is the mentioned urlencode(): It has to work on bytes to be reliable but it has no clue on the proper encoding so you need to tell that function Yes the, I know about the meaning, just take this byte sequence. A good thing would be to check the archives where most reasons were posted before. johannes For us users who have the luxury of not needing to deal with unicode, I expect that there is a steep learning curve in : 1 - Understanding why we need it. 2 - How we use it. 3 - Where does it all go wrong. 4 - How do we fix it when it does. In truth, if it all just worked, there would be no problem. But nothing ever just works. As someone who has been very happy with my ASCII character set, this whole thing seems extremely complicated and the potential for abuse, horrendous. I hope this is just FUD. It seems a LOT of effort has gone into unicode and it does seem that a lot of changes have had to be made. I'm all for improving and adhering to standards and even though I'm on the extreme fringe here, I believe adding Unicode is a good thing for PHP. But it will be needing a LOT of good quality documentation about this to help ISPs and Users. Its all well and good for a chosen few to understand the n'th degree of unicode, but a lot of the rest of us are in the dark on this. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants!
Re: [PHP-DEV] PHP 6 Preview
Hi Wez, On 5/23/07, Wez Furlong [EMAIL PROTECTED] wrote: On 5/21/07, Antony Dovgal [EMAIL PROTECTED] wrote: There is EXTENSIONS file (in the sources root dir) which lists extensions along with their maintainers. PECL has its own way to indicate the maintainers too (checkout the package.xml files), so that extensions file, which has almost never been up to date, isn't the definitive source of information. I can imagine something similar using the EXTENSION/CREDITS files. As long as we have valid emails, it should work well. No need to assign to one of the maintainers as they will all get the emails. Will it help us to work more or faster? No idea ;-) --Wez. (who's not really in this thread anymore. This post is a figment of your imagination) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Unicode extension in PHP6
On 23/05/07, Steph Fox [EMAIL PROTECTED] wrote: Nice article in the May edition of php|arch. Which _might_ make it online today if we're lucky..! Excellent! As a subscriber I'll be reading it avidly. Is PHP6 in a state able to be used? For Windows XP that is? -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Unicode extension in PHP6
On 5/23/07, Richard Quadling [EMAIL PROTECTED] wrote: Is PHP6 in a state able to be used? For Windows XP that is? in a state to be tested would be more correct :) -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Unicode extension in PHP6
Ah! So with this article in php|Architect and PHP6, we should be able to see how things work! Looking forward to it. On 23/05/07, Alexey Zakhlestin [EMAIL PROTECTED] wrote: On 5/23/07, Richard Quadling [EMAIL PROTECTED] wrote: Is PHP6 in a state able to be used? For Windows XP that is? in a state to be tested would be more correct :) -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
The point you're missing is that those features all belong in the firebird driver, not in PDO itself. --Wez. On 5/23/07, Lester Caine [EMAIL PROTECTED] wrote: Wez Furlong wrote: On 5/7/07, Lester Caine [EMAIL PROTECTED] wrote: No one has time to work on the Firebird PDO driver because we still need the main driver to provide the functions PDO does not support. Umm, no. Nobody has time for firebird because nobody uses it. I ask people about Firebird at each conference and I've never had more than about 1 in 50 people admit to ever having used it, and those are shaky hands going up--we're not talking die-hard firebird users here. As for PDO missing pieces for Firebird, that's also untrue. Perhaps you don't understand the PDO architecture, but PDO was designed by taking into account every database client API; it has hooks to cater for just about every conceivable way of passing data into and out of a database API. It's the firebird driver that needs work. No Wez - As far as I am concerned I need to load the non PDO driver for those areas that PDO does not support. As well as the PDO driver for the data based stuff *IF* I wanted to go down that route. But at present there is no good reason to switch. User security, Event management, Services interface functions are not data based and while some of those functions are being moved into the Firebird SQL, things like Events can not go that route. Now you may think that everything at the database end should be controlled via SQL, and that is probably the case, but as we have discussed long ago, *WE* still need ADOdb to provide the SQL abstraction so there is little incentive to work on PDO/Firebird/ADOdb when the current Firebird/ADOdb combination is fine and are currently working ( and ADOdbLite is the 'compact' version ). While ADOdb does support PDO, the best performance is still obtained with the raw drivers for each engine. If we are NOT working with multiple engines, then we work with the raw driver so again there is little need to spend scarce time replacing something that is working and has more facilities. So until you provide a very good reason why we need to change - it's not going to happen. BLOB and parameter handling in the raw Firebird driver are a lot more flexible and simply sending a query with an optional array of parameters is much easier than HAVING to prepare everything - especially when the engine will cache things automatically anyway. PDO simply changes the ground rules without solving any particular problem as has been said all along. Now you may well convince people that all the native drivers should be dropped from PHP and only PDO supplied but I hope that does not happen and that we have a PROPER debate on an abstract database layer. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
I'd modify that to say that no one with the C skills is interested in taking it over, and there is almost no incentive to do this because no one uses it. --Wez. On 5/23/07, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: But anyways, the problem is of course not that we are uninterested in Firebird, but simply that nobody with the C hacker skills has taken this over yet. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Wez Furlong wrote: I'd modify that to say that no one with the C skills is interested in taking it over, and there is almost no incentive to do this because no one uses it. I would not say that on the firebird-php list Wez - one hell of a lot of people rely on it for their livelyhood. I know - I'm one of them. I don't have time to waste to move perfectly functional code from one driver to another just because others say that is what must happen. I'll stick with the driver that *IS* working, and uses the optimal method of getting SQL in and out of the engine rather than having to take a second best route. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Lester Caine wrote: Wez Furlong wrote: I'd modify that to say that no one with the C skills is interested in taking it over, and there is almost no incentive to do this because no one uses it. I would not say that on the firebird-php list Wez - one hell of a lot of people rely on it for their livelyhood. I know - I'm one of them. I don't have time to waste to move perfectly functional code from one driver to another just because others say that is what must happen. I'll stick with the driver that *IS* working, and uses the optimal method of getting SQL in and out of the engine rather than having to take a second best route. Lester, the point is simple. Very few things in PHP get done because someone besides the actual developer needs it. In some cases this need is created by a corporate sponsor as in the case of the oci8 driver. But you can argue all you want on this, the fact of the matter is that importance in PHP is determined by the assumption that anything important will have someone to hack on. Of course some important things might just be unlucky in this setup and Firebird seems to be hit by that. So I suggest that you go hunt on firebird-php for some people with hacking skills, that are interested in playing with PDO. That being said, you are right the native extensions are slightly faster (unless you are making heavy use of fetchAll()) and they work nice and provide more features. That beind said, a lot of shiny new software is build on top of PDO and if nobody in the Firebird community picks up the PDO driver, all the Firebird users will be left out in the cold. But again, if nobody with C hacking skills is feeling sufficient pain over this, the assumption is that the pool of users is too small or the pain is too small. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mbstring: missing support for hex numeric entities xHHHH;
mbstring does not support numeric entities in HTML code. For example:
echo urlencode( mb_convert_encoding(#x0415;, UTF-8, HTML-ENTITIES) );
displays %F2%AF%B8%9F rather than the expected %D0%95.
This bug was detected by Nick Wedd [EMAIL PROTECTED] and reported in the
newsgroup comp.lang.php, Message-ID: [EMAIL PROTECTED].
I'd found the bug in the file ext/mbstring/libmbfl/filters/mbfilter_htmlent.c
and added these features:
- decode hex entities x;
- detect invalid digits
- detect digits missing at all
- detect values out of the range 0-0x
Invalid values are returned verbatim.
Apparently the right place for this patch should be
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/php-i18n/
but currently the project isn't no more hosted there.
The patch for ext/mbstring/libmbfl/filters/mbfilter_htmlent.c follows:
173a174,217
static int mbfl_decode_numeric_entity(char *s, int s_len)
/*
s = numeric entity ddd or x
return: numeric value or -1 if not inside [0,0x] or invalid digits
*/
{
int ent, pos, c, d;
ent = 0;
if (*s == 'x' || *s == 'X') {
/* hexadecimal base */
if ( s_len 2 )
return -1; /* no digits found */
for (pos=1; poss_len; pos++) {
c = s[pos];
if (isdigit(c))
d = c - '0';
else if (isxdigit(c))
d = tolower(c) - 'a' + 10;
else
return -1; /* invalid hex digit */
ent = (ent 4) + d;
if (ent 0x)
return -1; /* too big */
}
} else {
/* decimal base */
if ( s_len 1 )
return -1; /* no digits found */
for (pos=0; poss_len; pos++) {
c = s[pos];
if (! isdigit(c) )
return -1; /* invalid dec char */
ent = ent*10 + (c - '0');
if (ent 0x)
return -1; /* too big */
}
}
return ent;
}
192,193c236,246
for (pos=2; posfilter-status; pos++) {
ent = ent*10 + (buffer[pos] - '0');
---
ent = mbfl_decode_numeric_entity(buffer[2],
filter-status - 2);
if( ent = 0 ){
CK((*filter-output_function)(ent,
filter-data));
filter-status = 0;
/*php_error_docref(ref.mbstring
TSRMLS_CC, E_NOTICE, mbstring decoded '%s'=%d, buffer, ent);*/
} else {
/* failure */
buffer[filter-status++] = ';';
buffer[filter-status] = 0;
/* php_error_docref(ref.mbstring
TSRMLS_CC, E_WARNING, mbstring cannot decode '%s', buffer); */
mbfl_filt_conv_html_dec_flush(filter);
195,197d247
CK((*filter-output_function)(ent,
filter-data));
filter-status = 0;
/*php_error_docref(ref.mbstring TSRMLS_CC,
E_NOTICE, mbstring decoded '%s'=%d, buffer, ent);*/
Best regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Unicode extension in PHP6
It would help if you provided some context. Why do you need to create binary strings in your apps? -Andrei On May 23, 2007, at 5:09 AM, Rangel Reale wrote: Yes, I understand why urlencode does not work with unicode, but the problem is, when unicode is turned on, 100% of the times I need to use it, I need to use the (binary) typecast (as normally I create my params as variables), or create the variables as binary, all of which requires me to write PHP 6 specific code. Would it not be possible for the function just try to convert the string do binary itself, and issue a warning if not possible? I would of course only use compatible strings, if I didn't, my bad. But forcing us writing portable code for 100% incompatible source code, where it really isn't needed... is hard for me to undestand the motives. - Original Message - From: Johannes Schlüter [EMAIL PROTECTED] To: Rangel Reale [EMAIL PROTECTED] Cc: internals@lists.php.net Sent: Tuesday, May 22, 2007 10:12 PM Subject: Re: [PHP-DEV] PHP Unicode extension in PHP6 Hi Rangel, for PHP 6 the basic string type ist unicode string and most functions will accept these as primary type. But there are a few exceptions where unicode, for different reason, makes no sense. There you have to pass a binary string - an example is the mentioned urlencode(): It has to work on bytes to be reliable but it has no clue on the proper encoding so you need to tell that function Yes the, I know about the meaning, just take this byte sequence. A good thing would be to check the archives where most reasons were posted before. johannes On Tue, 2007-05-22 at 15:16 -0300, Rangel Reale wrote: I'm also having problems with this bstring incompatibility with older versions, I know I shouldn't need to have binary strings, but the problem is, the PHP funcions does not accept an Unicode string (urlencode), so it gives me a warning. In the future will 100% of the functions accept an unicode string? If so, then to me this should not be a problem. - Original Message - From: Tomas Kuliavas [EMAIL PROTECTED] To: Jared Williams [EMAIL PROTECTED] Cc: internals@lists.php.net Sent: Tuesday, May 22, 2007 2:52 PM Subject: RE: [PHP-DEV] PHP Unicode extension in PHP6 Recent versions of PHP5, has a binary string introducer. echo strlen(b\xC4\x85); I have already said to Stefan. It is not an option. I need backwards compatibility. If older PHP versions fail with E_PARSE errors, I can't use it. I can't maintain two different library versions, because issue affect lots of functions. Currently I can only stop script execution, if unicode.semantics=on is detected. Main complain is the fact that scripts can't control mbstring.func_overload and unicode.semantics. Only script writters know, if their code depends on overloading or unicode syntax. End users might be unable to change settings in PHP_INI_PERDIR. Thanks to all for feedback. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 15/5/2007 10:47 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 15/5/2007 10:47 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Unicode extension in PHP6
No problem. I just can't use it. It does not pass even basic must work on Debian Stable test. Option creates parsing errors in older PHP versions and I can't wrap it with PHP6 check. Such code must be stored in separate libraries loaded only in PHP6 and issue affects way to many functions. If scripts are portable, they should work on any PHP version without tweaks in PHP_INI_PERDIR configuration. Minimal 5.2.1+ requirement is not acceptable. We are not talking about code designed to work only on some selected setup. unicode.semantics is the third PHP configuration option that can seriously break things. First two are 'variables_order' and 'gpc_order'. Trust me, it was the only available solution we came up with that balanced backwards compatibility and the new language semantics. Would you rather that PHP 6 just updated language semantics without giving you an option to turn certain behaviors off? IMHO, if you are set on working with binary strings exclusively, then you should not turn unicode.semantics=on. Why are you trying to turn it on if you are not using Unicode features? -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Still having lstat trouble
Hi, I've posted this problem some time ago, but never got a real answer and it is still bothering me a lot. My problem is that PHP does not recognize a symlink as a symlink. It seems to be dereferenced by functions like 'lstat', 'is_link' and 'filetype'. And that isn't supposed to happen. The bug http://bugs.php.net/bug.php?id=17128 describes my problem exactly, but is marked as bogus. Well this problem sure isn't bogus for me. I'm having this problem, since I've updated from Ubuntu Edgy to Feisty. Before that all worked fine. Please note that I've not installed PHP from a repository, but I build the latest CVS version of PHP 5 regularly myself. Also this problem only occurs in the Apache 2 SAPI, not in the CLI version. Let me give an example, to make the problem clear. ? $symlink = '/tmp/link-test'; $target = '/tmp/pear'; if (!file_exists($target)) trigger_error(Target '$target' does not exist, E_USER_ERROR); if (file_exists($symlink) !unlink($symlink)) trigger_error(Could not delete '$symlink', E_USER_ERROR); symlink($target, $symlink); clearstatcache(); /* This should output 'link' */ echo filetype($symlink), \n; /* This should output 'link' */ echo is_link($symlink) ? 'link' : 'not a link', \n; /* This should output 'differ' */ echo lstat($symlink) === stat($target) ? 'same' : 'differ'; ? Expected: link link differ Actual: dir not a link same I understand that if I post this as a bug, it is tested, can't be reproduced and marked as bogus. Therefore, I could appreciate it if someone could please point me towards a way to pinpoint the problem. I've run a strace already, but can't notice anything weird. Thanks for any help, Arnold -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Unicode extension in PHP6
To pass as parameter to functions that do not accept unicode (like urlencode). Say I want to prepare a variable no create an url: ?php $parametervalue='abc:xyz'; $url='link.php?param='.urlencode($parametervalue); ? This works fine on php =5, but on 6 it gives a warning: urlencode() expects parameter 1 to be strictly a binary string, Unicode string given. I need to make the variable a binary string with $parametervalue=b'abc:xyz'; or typecast in urlencode $url='link.php?param='.urlencode((binary)$parametervalue); Both breaks the code in PHP = 5, and the worst, with nothing we can do (if it would be C, we could just put some #ifdef, but this is php). []s Rangel - Original Message - From: Andrei Zmievski [EMAIL PROTECTED] To: Rangel Reale [EMAIL PROTECTED] Cc: internals@lists.php.net Sent: Wednesday, May 23, 2007 4:50 PM Subject: Re: [PHP-DEV] PHP Unicode extension in PHP6 It would help if you provided some context. Why do you need to create binary strings in your apps? -Andrei On May 23, 2007, at 5:09 AM, Rangel Reale wrote: Yes, I understand why urlencode does not work with unicode, but the problem is, when unicode is turned on, 100% of the times I need to use it, I need to use the (binary) typecast (as normally I create my params as variables), or create the variables as binary, all of which requires me to write PHP 6 specific code. Would it not be possible for the function just try to convert the string do binary itself, and issue a warning if not possible? I would of course only use compatible strings, if I didn't, my bad. But forcing us writing portable code for 100% incompatible source code, where it really isn't needed... is hard for me to undestand the motives. - Original Message - From: Johannes Schlüter [EMAIL PROTECTED] To: Rangel Reale [EMAIL PROTECTED] Cc: internals@lists.php.net Sent: Tuesday, May 22, 2007 10:12 PM Subject: Re: [PHP-DEV] PHP Unicode extension in PHP6 Hi Rangel, for PHP 6 the basic string type ist unicode string and most functions will accept these as primary type. But there are a few exceptions where unicode, for different reason, makes no sense. There you have to pass a binary string - an example is the mentioned urlencode(): It has to work on bytes to be reliable but it has no clue on the proper encoding so you need to tell that function Yes the, I know about the meaning, just take this byte sequence. A good thing would be to check the archives where most reasons were posted before. johannes On Tue, 2007-05-22 at 15:16 -0300, Rangel Reale wrote: I'm also having problems with this bstring incompatibility with older versions, I know I shouldn't need to have binary strings, but the problem is, the PHP funcions does not accept an Unicode string (urlencode), so it gives me a warning. In the future will 100% of the functions accept an unicode string? If so, then to me this should not be a problem. - Original Message - From: Tomas Kuliavas [EMAIL PROTECTED] To: Jared Williams [EMAIL PROTECTED] Cc: internals@lists.php.net Sent: Tuesday, May 22, 2007 2:52 PM Subject: RE: [PHP-DEV] PHP Unicode extension in PHP6 Recent versions of PHP5, has a binary string introducer. echo strlen(b\xC4\x85); I have already said to Stefan. It is not an option. I need backwards compatibility. If older PHP versions fail with E_PARSE errors, I can't use it. I can't maintain two different library versions, because issue affect lots of functions. Currently I can only stop script execution, if unicode.semantics=on is detected. Main complain is the fact that scripts can't control mbstring.func_overload and unicode.semantics. Only script writters know, if their code depends on overloading or unicode syntax. End users might be unable to change settings in PHP_INI_PERDIR. Thanks to all for feedback. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 15/5/2007 10:47 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 15/5/2007 10:47 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 15/5/2007 10:47 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Still having lstat trouble
So, would this be Ubuntu 7.04? I happen to have one of those boxes sitting here: 5:52pm ubuntu:~ mkdir /tmp/pear 5:52pm ubuntu:~ cat /etc/issue Ubuntu 7.04 \n \l 5:52pm ubuntu:~ uname -a Linux ubuntu 2.6.20-15-server #2 SMP Sun Apr 15 07:41:34 UTC 2007 i686 GNU/Linux 5:52pm ubuntu:~ php p link link differ 5:52pm ubuntu:~ l /tmp | grep link lrwxrwxrwx 1 rasmus rasmus9 2007-05-23 17:52 link-test - /tmp/pear/ The 'p' script is just a copy of paste of your script from this message. -Rasmus Arnold Daniels wrote: Hi, I've posted this problem some time ago, but never got a real answer and it is still bothering me a lot. My problem is that PHP does not recognize a symlink as a symlink. It seems to be dereferenced by functions like 'lstat', 'is_link' and 'filetype'. And that isn't supposed to happen. The bug http://bugs.php.net/bug.php?id=17128 describes my problem exactly, but is marked as bogus. Well this problem sure isn't bogus for me. I'm having this problem, since I've updated from Ubuntu Edgy to Feisty. Before that all worked fine. Please note that I've not installed PHP from a repository, but I build the latest CVS version of PHP 5 regularly myself. Also this problem only occurs in the Apache 2 SAPI, not in the CLI version. Let me give an example, to make the problem clear. ? $symlink = '/tmp/link-test'; $target = '/tmp/pear'; if (!file_exists($target)) trigger_error(Target '$target' does not exist, E_USER_ERROR); if (file_exists($symlink) !unlink($symlink)) trigger_error(Could not delete '$symlink', E_USER_ERROR); symlink($target, $symlink); clearstatcache(); /* This should output 'link' */ echo filetype($symlink), \n; /* This should output 'link' */ echo is_link($symlink) ? 'link' : 'not a link', \n; /* This should output 'differ' */ echo lstat($symlink) === stat($target) ? 'same' : 'differ'; ? Expected: link link differ Actual: dir not a link same I understand that if I post this as a bug, it is tested, can't be reproduced and marked as bogus. Therefore, I could appreciate it if someone could please point me towards a way to pinpoint the problem. I've run a strace already, but can't notice anything weird. Thanks for any help, Arnold -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP needs better function organization, naming and parameter specifications
Hello guys/girls, I was told to send my suggestions to this list (and I'm offering my help/time too...) D. -Original Message- From: Jay Blanchard [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 23, 2007 1:58 PM To: Daevid Vincent; [EMAIL PROTECTED] Subject: RE: [PHP] PHP needs better funtion organization, naming and parameter specifications. WAS: Form Validation Issues [snip] ...several valid points... [/snip] Send this all to the developer's list -Original Message- From: Daevid Vincent [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 23, 2007 1:55 PM To: [EMAIL PROTECTED] Subject: [PHP] PHP needs better funtion organization, naming and parameter specifications. WAS: Form Validation Issues On Thursday 24 May 2007 00:51, Greg Donald wrote: As I watch PHP de-evolve into Java, I find myself wanting something lighter weight and with a smaller syntax. PHP has long since spawned into something uncontrollable. Compare the number of functions (and its aliases) to eg Ruby. The string functions in particular are absolutely bloated, eg ltrim, trim rtrim - WTF. Why not just have trim() and have the option of specifying whether left/right/both? The same goes for the case-sensitive and case-insensitive versions of functions. Amen. The other thing is why isn't there any consistency with the function names?! It seems they're just randomly picked by whatever developer decided to make it. Isn't there some governing body who can at least make things consistent? Examples: = isset() vs. is_null() htmlentities() vs html_entity_decode() (and why is there htmlentities() and htmlentities both listed here: http://us2.php.net/manual/en/ref.strings.php ) quoted_printable_decode() vs quotemeta() strnatcasecmp - Case insensitive string comparisons using a natural order algorithm strnatcmp - String comparisons using a natural order algorithm strncasecmp - Binary safe case-insensitive string comparison of the first n characters strncmp - Binary safe string comparison of the first n characters strcasecmp - Binary safe case-insensitive string comparison Why do we need all those. Use a 'binary' flag. And secondly, why does this have the word case instead of i like the other string functions use? Why do I have to do this extra function call when I bet a majority of the time this is what you want: $bar = 'HELLO WORLD!'; $bar = ucfirst(strtolower($bar)); // Hello world! Why can't ucfirst() have a parameter to do what I want. arsort() and asort() should be array_sort() and array_sort_reverse() natcasesort() should be array_sort_natural() with parameters to make it case insensitive. Same for the rest of the sort functions. Why isn't unlink() named file_delete() as that's what it does? It's counter-intuitive. Why do we need lchgrp() and chgrp() -- why do I care if it's a link or not? Use a parameter flag if this is really a concern for people. No specific examples, but I know I've run into this stuff before: Sometimes the needle is first, sometimes the haystack is. Sometimes the pattern and subject are out of order. Also simple things like naming conventions: The ereg* functions call it $string, but the preg functions call it $subject Etc... I'm sure I could list easily 50 or 100 more examples here, but the point is that PHP needs some structure and organization and a document/spec that says how functions should be named and the order of parameters, ideally with 'optional' ones to the end (much like they are now in most cases). I would like them all to be prefixed with the general category they're in, so it's easy to find them. Such as array_*, str_*, file_*, date_*etc. I think someone should go through and make proper names for all the current functions, keeping aliases for the existing ones to what they are now (so as not to break everyone's code), but only show the new proper names in the manual so developers don't use the sloppy old names. That would at least start us on the right path to fixing this chaos. BTW, don't get me wrong, I LOVE PHP. I've used it every day for maybe 10 years now. I just don't think the current methodology (or lack thereof) can keep sustaining the growth of the releases. I also think it's increasingly confusing for new users to learn. I'm still confused and always referencing the docs for function names and parameter orders. If there needs to be a governing body for the naming, etc as mentioned, I'm happy to volunteer my time / talent. Contact me off list for resume, etc and set me up an SVN account and I'll bring my machette and get this fixed. :) Daevid Vincent http://daevid.com -Original Message- From: Daevid Vincent [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 23, 2007 3:08 PM Cc: 'Crayon Shin Chan' Subject: RE: [PHP] PHP needs better funtion organization, naming and parameter specifications. WAS: Form Validation Issues Send this all to the developer's list Too late now. The damage has been
Re: [PHP-DEV] Still having lstat trouble
Brian Moon wrote: Rasmus Lerdorf wrote: 5:52pm ubuntu:~ php p I think he said Also this problem only occurs in the Apache 2 SAPI, not in the CLI version. Works fine under Apache1. I don't have Apache2 handy on this box. But I can't see this being affected by the SAPI in any way other than user permissions and/or some sort of SELinux restriction. As in, things external to PHP itself. So, if someone who knows their way around strace can reproduce this problem and show me the series of syscalls and their exit status, we can probably figure out what is happening. I'm about 90% sure this is not a PHP problem, but rather a system configuration problem. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Still having lstat trouble
I'm getting similar results from a RHEL 4 box we have here, its running
5.2.3-dev.
[EMAIL PROTECTED] [/tmp] # cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
[EMAIL PROTECTED] [~] # uname -a
Linux scarlet 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 18:00:32 EDT 2006
i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] [/tmp] # php test.php
dir
not a link
same
strace for the during execution is.
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
readlink(/tmp/link-test, /tmp/pear, 4096) = 9
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, dir, 3dir) = 3
write(1, \n, 1) = 1
write(1, not a link, 10not a link) = 10
write(1, \n, 1) = 1
time(NULL) = 1179958429
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, same, 4same) = 4
Scott
Arnold Daniels wrote:
Hi,
I've posted this problem some time ago, but never got a real answer and
it is still bothering me a lot.
My problem is that PHP does not recognize a symlink as a symlink. It
seems to be dereferenced by functions like 'lstat', 'is_link' and
'filetype'. And that isn't supposed to happen.
The bug http://bugs.php.net/bug.php?id=17128 describes my problem
exactly, but is marked as bogus. Well this problem sure isn't bogus for
me. I'm having this problem, since I've updated from Ubuntu Edgy to
Feisty. Before that all worked fine.
Please note that I've not installed PHP from a repository, but I build
the latest CVS version of PHP 5 regularly myself. Also this problem only
occurs in the Apache 2 SAPI, not in the CLI version.
Let me give an example, to make the problem clear.
?
$symlink = '/tmp/link-test';
$target = '/tmp/pear';
if (!file_exists($target)) trigger_error(Target '$target' does not
exist, E_USER_ERROR);
if (file_exists($symlink) !unlink($symlink)) trigger_error(Could
not delete '$symlink', E_USER_ERROR);
symlink($target, $symlink);
clearstatcache();
/* This should output 'link' */
echo filetype($symlink), \n;
/* This should output 'link' */
echo is_link($symlink) ? 'link' : 'not a link', \n;
/* This should output 'differ' */
echo lstat($symlink) === stat($target) ? 'same' : 'differ';
?
Expected:
link
link
differ
Actual:
dir
not a link
same
I understand that if I post this as a bug, it is tested, can't be
reproduced and marked as bogus. Therefore, I could appreciate it if
someone could please point me towards a way to pinpoint the problem.
I've run a strace already, but can't notice anything weird.
Thanks for any help,
Arnold
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Still having lstat trouble
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, 0xbff229ec) = -1 ENOENT (No such file or
directory)
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
symlink(/tmp/pear, /tmp/link-test) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
stat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, differ, 6differ) = 6
Scott MacVicar wrote:
I'm getting similar results from a RHEL 4 box we have here, its running
5.2.3-dev.
[EMAIL PROTECTED] [/tmp] # cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
[EMAIL PROTECTED] [~] # uname -a
Linux scarlet 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 18:00:32 EDT 2006
i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] [/tmp] # php test.php
dir
not a link
same
strace for the during execution is.
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
That means /tmp/link-test exists already, otherwise lstat returns -1.
Here is what I see if the link already exists when I run my script:
access(/tmp/pear, F_OK) = 0
access(/tmp/link-test, F_OK) = 0
unlink(/tmp/link-test)= 0
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, 0xbff229ec) = -1 ENOENT (No such file or
directory)
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
symlink(/tmp/pear, /tmp/link-test) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
stat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, differ, 6differ) = 6
So did you leave out those access() calls, and did they fail, or did the
unlink() fail perhaps?
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Still having lstat trouble
Miscopied, a full strace is:
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access(/tmp/pear, F_OK) = 0
time(NULL) = 1179959483
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
readlink(/tmp/link-test, /tmp/pear, 4096) = 9
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access(/tmp/pear, F_OK) = 0
unlink(/tmp/link-test)= 0
time(NULL) = 1179959483
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, 0xbff2137c) = -1 ENOENT (No such file or
directory)
time(NULL) = 1179959483
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
symlink(/tmp/pear, /tmp/link-test) = 0
time(NULL) = 1179959483
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
readlink(/tmp/link-test, /tmp/pear, 4096) = 9
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, dir, 3dir) = 3
write(1, \n, 1
) = 1
write(1, not a link, 10not a link) = 10
write(1, \n, 1
) = 1
time(NULL) = 1179959483
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, same, 4same) = 4
SELinux is disabled on the box.
Scott
Rasmus Lerdorf wrote:
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, 0xbff229ec) = -1 ENOENT (No such file or
directory)
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
symlink(/tmp/pear, /tmp/link-test) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
stat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, differ, 6differ) = 6
Scott MacVicar wrote:
I'm getting similar results from a RHEL 4 box we have here, its running
5.2.3-dev.
[EMAIL PROTECTED] [/tmp] # cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
[EMAIL PROTECTED] [~] # uname -a
Linux scarlet 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 18:00:32 EDT 2006
i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] [/tmp] # php test.php
dir
not a link
same
strace for the during execution is.
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
That means /tmp/link-test exists already, otherwise lstat returns -1.
Here is what I see if the link already exists when I run my script:
access(/tmp/pear, F_OK) = 0
access(/tmp/link-test, F_OK) = 0
unlink(/tmp/link-test)= 0
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, 0xbff229ec) = -1 ENOENT (No such file or
directory)
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
symlink(/tmp/pear, /tmp/link-test) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
stat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, differ, 6differ) = 6
So did you leave out those access() calls, and did they fail, or did the
unlink() fail perhaps?
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Still having lstat trouble
Works as expected on my Mac (no strace on my Mac). On my Gentoo 64-bit
server, I get the wrong data from Apache2 and CLI. On my 32-bit
Gentoo server, without Apache 2, I get the correct answer from apache
and cli. On my 32-bit Gentoo server with Apache 2 I get a wrong answer
from Apache and cli.
We build our PHP on these servers with the same options via emerge. The
only difference is Apache 2. What the hell?
# uname -a
Linux proxy1 2.6.18-gentoo-r6 #1 SMP Thu Feb 8 07:32:31 EST 2007 x86_64
Dual-Core AMD Opteron(tm) Processor 2210 AuthenticAMD GNU/Linux
# php foobar.php
dir
not a link
same
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access(/tmp/pear, F_OK) = 0
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
readlink(/tmp/link-test, /tmp/pear, 4096) = 9
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access(/tmp/pear, F_OK) = 0
unlink(/tmp/link-test)= 0
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/link-test, 0x7fff3f48fb70) = -1 ENOENT (No such file or
directory)
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
symlink(/tmp/pear, /tmp/link-test) = 0
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
readlink(/tmp/link-test, /tmp/pear, 4096) = 9
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b906b634000
write(1, dir, 3dir) = 3
write(1, \n, 1
) = 1
write(1, not a link, 10not a link) = 10
write(1, \n, 1
) = 1
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, same, 4same) = 4
32-bit Gentoo however acts as expected.
$ uname -a
Linux deadpool 2.6.11-gentoo-r6 #1 SMP Thu Apr 14 07:52:09 EDT 2005 i686
Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel GNU/Linux
php test.php
link
link
differ
access(/tmp/pear, F_OK) = 0
access(/tmp/link-test, F_OK) = 0
unlink(/tmp/link-test)= 0
time(NULL) = 1179959743
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=14416, ...}) = 0
lstat64(/tmp/link-test, 0xbfff5e4c) = -1 ENOENT (No such file or
directory)
time(NULL) = 1179959743
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=14416, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
symlink(/tmp/pear, /tmp/link-test) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb78b1000
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
stat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
write(1, differ, 6differ) = 6
Rasmus Lerdorf wrote:
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, 0xbff229ec) = -1 ENOENT (No such file or
directory)
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
symlink(/tmp/pear, /tmp/link-test) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
stat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, differ, 6differ) = 6
Scott MacVicar wrote:
I'm getting similar results from a RHEL 4 box we have here, its running
5.2.3-dev.
[EMAIL PROTECTED] [/tmp] # cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
[EMAIL PROTECTED] [~] # uname -a
Linux scarlet 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 18:00:32 EDT 2006
i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] [/tmp] # php test.php
dir
not a link
same
strace for the during execution is.
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test,
Re: [PHP-DEV] Re: Still having lstat trouble
Which filesystems is /tmp on on the various boxes? tmpfs related perhaps?
-Rasmus
Brian Moon wrote:
Works as expected on my Mac (no strace on my Mac). On my Gentoo 64-bit
server, I get the wrong data from Apache2 and CLI. On my 32-bit Gentoo
server, without Apache 2, I get the correct answer from apache and cli.
On my 32-bit Gentoo server with Apache 2 I get a wrong answer from
Apache and cli.
We build our PHP on these servers with the same options via emerge. The
only difference is Apache 2. What the hell?
# uname -a
Linux proxy1 2.6.18-gentoo-r6 #1 SMP Thu Feb 8 07:32:31 EST 2007 x86_64
Dual-Core AMD Opteron(tm) Processor 2210 AuthenticAMD GNU/Linux
# php foobar.php
dir
not a link
same
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access(/tmp/pear, F_OK) = 0
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
readlink(/tmp/link-test, /tmp/pear, 4096) = 9
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access(/tmp/pear, F_OK) = 0
unlink(/tmp/link-test)= 0
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/link-test, 0x7fff3f48fb70) = -1 ENOENT (No such file or
directory)
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
symlink(/tmp/pear, /tmp/link-test) = 0
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
readlink(/tmp/link-test, /tmp/pear, 4096) = 9
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b906b634000
write(1, dir, 3dir) = 3
write(1, \n, 1
) = 1
write(1, not a link, 10not a link) = 10
write(1, \n, 1
) = 1
lstat(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, same, 4same) = 4
32-bit Gentoo however acts as expected.
$ uname -a
Linux deadpool 2.6.11-gentoo-r6 #1 SMP Thu Apr 14 07:52:09 EDT 2005 i686
Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel GNU/Linux
php test.php
link
link
differ
access(/tmp/pear, F_OK) = 0
access(/tmp/link-test, F_OK) = 0
unlink(/tmp/link-test)= 0
time(NULL) = 1179959743
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=14416, ...}) = 0
lstat64(/tmp/link-test, 0xbfff5e4c) = -1 ENOENT (No such file or
directory)
time(NULL) = 1179959743
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=14416, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
symlink(/tmp/pear, /tmp/link-test) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb78b1000
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
stat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
write(1, differ, 6differ) = 6
Rasmus Lerdorf wrote:
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/link-test, 0xbff229ec) = -1 ENOENT (No such file or
directory)
lstat64(/tmp, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
symlink(/tmp/pear, /tmp/link-test) = 0
lstat64(/tmp/link-test, {st_mode=S_IFLNK|0777, st_size=9, ...}) = 0
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
write(1, link, 4link) = 4
write(1, \n, 1
) = 1
stat64(/tmp/pear, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
write(1, differ, 6differ) = 6
Scott MacVicar wrote:
I'm getting similar results from a RHEL 4 box we have here, its running
5.2.3-dev.
[EMAIL PROTECTED] [/tmp] # cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
[EMAIL PROTECTED] [~] # uname -a
Linux scarlet 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 18:00:32 EDT 2006
i686 i686 i386 GNU/Linux
Re: [PHP-DEV] Re: Still having lstat trouble
Rasmus Lerdorf wrote: Which filesystems is /tmp on on the various boxes? tmpfs related perhaps? On all my systems, /tmp is just part of / which is ReiserFS. -- Brian Moon Senior Developer -- http://dealnews.com/ It's good to be cheap =) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
