Bug #50829 [Com]: php.ini directive pdo_mysql.default_socket is ignored
Edit report at http://bugs.php.net/bug.php?id=50829&edit=1 ID: 50829 Comment by: gnoodl+php at gmail dot com Reported by:giovanni at giacobbi dot net Summary:php.ini directive pdo_mysql.default_socket is ignored Status: Closed Type: Bug Package:PDO related Operating System: Linux PHP Version:5.3.2RC1 Block user comment: N New Comment: So we're at v5.3.3 and this bug is still around :( Status should be "Open" Previous Comments: [2010-07-23 20:21:24] joelataylor at gmail dot com I'm having this exact issue on 5.3.2 - installed via Zend Server. Having been hitting my head against a brick wall. I obviously can create a symbolic link, or use unix_socket - to point to the correct location - but would prefer localhost to work as expected. [2010-04-23 01:57:46] gnoodl at gmail dot com In which stable version does this fix appear. I've just upgraded to PHP 5.3.2 and whilst pdo_mysql.default_socket is returned correctly via ini_get(), attempting to make a connection results in the following exception SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/tmp/mysql.sock' FYI, my socket file resides at /var/lib/mysql/mysql.sock [2010-03-24 17:49:55] paul at boxuk dot com this, or a problem relating to this fix appears to be seg-faulting the pdo_mysql module on startup in ZTS mode bug #51216 is related commenting out REGISTER_INI_ENTRIES() in ext/pdo_mysql/pdo_mysql.c:68 php startup prevents the seg-fault configure line -- ./configure --enable-maintainer-zts --with-mysql --with-mysqli=mysqlnd --enable- pdo --with-pdo-mysql gdb output -- gdb sapi/cli/php GNU gdb Fedora (6.8-37.el5) This GDB was configured as "i386-redhat-linux-gnu"... (gdb) run Starting program: /php-5.3.2/sapi/cli/php [Thread debugging using libthread_db enabled] [New Thread 0xb7f776c0 (LWP 491)] [New Thread 0xb7d0db90 (LWP 494)] [Thread 0xb7d0db90 (LWP 494) exited] Program received signal SIGSEGV, Segmentation fault. 0x08347ff5 in zend_startup_module_ex (module=0x98d2720, tsrm_ls=0x98b7050) at /opt/BoxUK/install/php-5.3.2/Zend/zend_API.c:1618 1618EG(current_module) = NULL; module->name at this point is "pdo_mysql" [2010-02-03 21:00:21] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=294469 Log: Fixed bug #50829 (php.ini directive pdo_mysql.default_socket is ignored) [2010-01-26 13:15:59] il...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50829 -- Edit this bug report at http://bugs.php.net/bug.php?id=50829&edit=1
Req #46260 [Com]: __FILE__ should not resolve symlink paths
Edit report at http://bugs.php.net/bug.php?id=46260&edit=1 ID: 46260 Comment by: gnoodl+php at gmail dot com Reported by:bugs dot php dot net at callum-macdonald dot com Summary:__FILE__ should not resolve symlink paths Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Linux PHP Version:5.2.6 Block user comment: N Private report: N New Comment: $_SERVER["SCRIPT_FILENAME"] cannot be used in place of __FILE__ as it does not resolve the path of an included file. Eg, // file1.php include 'file2.php'; // file2.php echo $_SERVER['SCRIPT_FILENAME']; Executing file1.php will result in "/path/to/file1.php" Previous Comments: [2010-12-10 18:12:17] php at micropro dot cz I think I have a resoulution ... use $_SERVER["SCRIPT_FILENAME"] instead of __file__. It should work the same way, but is absolute path, not resolved. It works for me fine :-) [2010-11-10 16:52:41] jimmy at powerzone dot dk I agree. Hosting multiple PHP systems based on the same installation is no easy task, when __FILE__ is used in conjunction with symlinks. Very frustrating. I vote for a new contant; __FILEPATH__ which does not resolve symlinks. [2010-08-26 09:12:33] rix at mindginative dot com +1 for this. I encountered this issue today and was hoping that there's a better way not to resolve symlink in __FILE__. As suggested above, perhaps __FILE_LINK__ that either return the symlink path or false if none. [2009-09-26 21:01:15] miguel-php at cr dot uz Another vote for this. The current implementation does not seem like the proper way to treat symlinks, and it makes sharing included files between directories very difficult. I understand that changing this now has the potential to cause breakage in scripts that depend on the current behaviour. But there really does need to be a way for a file to find its own effective location. [2009-09-22 06:42:10] glideraerobatics at hotmail dot com I have the same problem with PHP. I have a slave site that shares most (but not all!) code with a master site using symlinks. The code consists of CLI scripts, web pages, and includes (one of which is a common include for setting up the include_path and error handling). It is critical that this include_path refers to paths in the slave site even though the real common include resides in the master site. I can't achieve this using __FILE__ unfortunately due to the symlink resolution problem. It would be nice to have an alternative to __FILE__, perhaps __LINK__, with unresolved symlinks. Please PHP developers add this!!! PHP needs it so much and it must be a very simple thing to add. In the mean time, I've created a function in the common include that jumps though hoops in order to set the include_path correctly by using argv[0] in CLI scripts (and traversing up until a htdocs dir is found) or else $_SERVER['DOCUMENT_ROOT'] in web scripts. It's horrible, but the only solution I've found so far. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=46260 -- Edit this bug report at http://bugs.php.net/bug.php?id=46260&edit=1
[PHP-BUG] Bug #60155 [NEW]: pdo_mysql.default_socket ignored
From: Operating system: Linux (Ubuntu) PHP version: 5.3.8 Package: PDO related Bug Type: Bug Bug description:pdo_mysql.default_socket ignored Description: The `pdo_mysql.default_socket` configuration setting is ignored when creating a PDO MySQL connection to "localhost" On my system, `pdo_mysql.default_socket` is set to "/var/run/mysqld/mysqld.sock" I've created a proof of concept here - http://staging.philipbrown.id.au/pdo- test.php Test script: --- $db = new PDO('mysql:host=localhost;dbname=test', 'pdotest', 'pdotest'); echo $db->getAttribute(PDO::ATTR_SERVER_VERSION); Expected result: Expect to see MySQL server version, eg "5.1.37-1ubuntu5.5" Actual result: -- PDOException with message "SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)" -- Edit bug report at https://bugs.php.net/bug.php?id=60155&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60155&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60155&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60155&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60155&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60155&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60155&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60155&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60155&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60155&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60155&r=support Expected behavior: https://bugs.php.net/fix.php?id=60155&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60155&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60155&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60155&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60155&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60155&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60155&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60155&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60155&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60155&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60155&r=mysqlcfg
Bug #49306 [Com]: socket settings are ignored
Edit report at https://bugs.php.net/bug.php?id=49306&edit=1 ID: 49306 Comment by: gnoodl+php at gmail dot com Reported by:aaatoja at o2 dot pl Summary:socket settings are ignored Status: Closed Type: Bug Package:PDO related Operating System: Opensuse 11.0 PHP Version:5.3.0 Block user comment: N Private report: N New Comment: Status should be OPEN. This bug is still present in 5.3.8 See http://staging.philipbrown.id.au/pdo-test.php Previous Comments: [2009-08-21 07:46:44] s...@php.net Automatic comment from SVN on behalf of tony2001 Revision: http://svn.php.net/viewvc/?view=revision&revision=287530 Log: fix build broken by the fix for bug #49306 [2009-08-20 12:13:49] il...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-08-20 12:13:39] s...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=287504 Log: Fixed bug #49306 (inside pdo_mysql default socket settings are ignored). [2009-08-20 08:46:51] aaatoja at o2 dot pl Description: PHP 5.3.0 My php.ini settings: [Pdo_mysql] pdo_mysql.default_socket= /srv/mysql/mysql.sock [MySQL] mysql.default_port = 3306 mysql.default_socket = /srv/mysql/mysql.sock Mysql or Mysqli connection works fine but PDO throws error: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) Socket must be hardcoded somewhere. -- Edit this bug report at https://bugs.php.net/bug.php?id=49306&edit=1