Bug #61317 [Opn]: phar locations in include_path are ignored
Edit report at https://bugs.php.net/bug.php?id=61317&edit=1
ID: 61317
User updated by:staff at pro-unreal dot de
Reported by:staff at pro-unreal dot de
Summary:phar locations in include_path are ignored
Status: Open
Type: Bug
Package:PHAR related
Operating System: Linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I am not sure if ':' as PATH_SEPARATOR is the problem, but it works when
calling include/require from a file inside a phar.
By the way ZendFramework for example uses preg_split to avoid the explode(':',
$path) issue.
Previous Comments:
[2012-06-20 07:31:00] stawi at plusnet dot pl
Isnt this related to fact that PATH_SEPARATOR is ":" which occurs in "phar://" ?
Try this:
set_include_path('phar://my.phar/lib:/usr/share/php');
var_export(explode(PATH_SEPARATOR, get_include_path()));
And the result is: array(
0 => 'phar',
1 => '//my.phar/lib',
2 => '/usr/share/php',
)
Not shure how it works inside, but for PHP programmer it inconvenient...
Some frameworks uses autoloaders which do explode() and then foreach array to
find file.
I know that changing PATH_SEPARATOR to other char can break a lot of code where
it was hardcored as ":", but if constans exists one should use it ;)
----------------
[2012-03-07 10:16:29] staff at pro-unreal dot de
Also applies for full phar URLs (Assuming the phar exists and contains the
described files).
Replace phar://my.phar/lib with full url like phar:///tmp/my.phar/lib
----------------
[2012-03-07 10:11:28] staff at pro-unreal dot de
Description:
When including files from outside a Phar all phar:// locations in include path
are ignored.
Test script:
---
include_path = phar://my.phar/lib:/usr/share/php
phar://my.phar/lib/Foo/Bar.php:
/usr/share/php/Foo/Bar.php
Test /tmp/test.php:
php -d include_path='phar://my.phar/lib:/usr/share/php' /tmp/test.php
Expected result:
Output should be:
YES: phar://my.phar/lib/Foo/Bar.php
Actual result:
--
Output is:
You should not see this!
--
Edit this bug report at https://bugs.php.net/bug.php?id=61317&edit=1
Bug #61317 [Com]: phar locations in include_path are ignored
Edit report at https://bugs.php.net/bug.php?id=61317&edit=1 ID: 61317 Comment by: staff at pro-unreal dot de Reported by:staff at pro-unreal dot de Summary:phar locations in include_path are ignored Status: Open Type: Bug Package:PHAR related Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Also applies for full phar URLs (Assuming the phar exists and contains the described files). Replace phar://my.phar/lib with full url like phar:///tmp/my.phar/lib Previous Comments: [2012-03-07 10:11:28] staff at pro-unreal dot de Description: When including files from outside a Phar all phar:// locations in include path are ignored. Test script: --- include_path = phar://my.phar/lib:/usr/share/php phar://my.phar/lib/Foo/Bar.php: /usr/share/php/Foo/Bar.php Test /tmp/test.php: php -d include_path='phar://my.phar/lib:/usr/share/php' /tmp/test.php Expected result: Output should be: YES: phar://my.phar/lib/Foo/Bar.php Actual result: -- Output is: You should not see this! -- Edit this bug report at https://bugs.php.net/bug.php?id=61317&edit=1
[PHP-BUG] Bug #61317 [NEW]: phar locations in include_path are ignored
From: Operating system: Linux PHP version: 5.3.10 Package: PHAR related Bug Type: Bug Bug description:phar locations in include_path are ignored Description: When including files from outside a Phar all phar:// locations in include path are ignored. Test script: --- include_path = phar://my.phar/lib:/usr/share/php phar://my.phar/lib/Foo/Bar.php: /usr/share/php/Foo/Bar.php Test /tmp/test.php: php -d include_path='phar://my.phar/lib:/usr/share/php' /tmp/test.php Expected result: Output should be: YES: phar://my.phar/lib/Foo/Bar.php Actual result: -- Output is: You should not see this! -- Edit bug report at https://bugs.php.net/bug.php?id=61317&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61317&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61317&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61317&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61317&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61317&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61317&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61317&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61317&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61317&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61317&r=support Expected behavior: https://bugs.php.net/fix.php?id=61317&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61317&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61317&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61317&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61317&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61317&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61317&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61317&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61317&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61317&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61317&r=mysqlcfg
Req #49618 [Com]: spl_autoload_register destroys __autoload hook
Edit report at https://bugs.php.net/bug.php?id=49618&edit=1
ID: 49618
Comment by: staff at pro-unreal dot de
Reported by:jost dot boekemeier at googlemail dot com
Summary:spl_autoload_register destroys __autoload hook
Status: Open
Type: Feature/Change Request
Package:SPL related
Operating System: *
PHP Version:5.2.11
Block user comment: N
Private report: N
New Comment:
How about that (php 5.3):
Please see the link posted with the bug report for all the details.
However, I think neither the user nor joomla nor I have to invent strange
workarounds for bugs in the php implementation. Any new introduced PHP feature
must be compatible with earlier PHP features, unless the earlier features have
been
deprecated and a clear migration path exists.
The old __autoload is neither deprecated nor is spl_autoload_register
compatible with
it. Whoever wrote it and the comment "This is because
spl_autoload_register() will
effectively replace the engine cache fo the __autoload function by either
spl_autoload() or spl_autoload_call(). " wrote a bug.
> Thus, calling spl_autoload_register() replaces __autoload()
If spl_autoload_register is intended to replace the old __autoload machinery,
the old
__autoload should have been deprecated and a clear migration path should have
been given to those using it.
[2009-09-23 07:23:07] sjo...@php.net
So the problem occurs with:
include('spl_autoload_register.php'); // uses spl_autoload_register
include('autoload.php'); // defines __autoload
[2009-09-22 17:39:32] jost dot boekemeier at googlemail dot com
> if (function_exists("__autoload")) spl_autoload_register("__ autoload")
Doesn't work. In line 7 __autoload is not yet defined.
Note that every line in the given example comes from a separate include()d php
library.
This is a link-time problem which only php can resolve: it must save a legacy
__autoload handler before creating the spl_autoload stack and call the legacy
autoload after all other registered spl_autoload hooks.
[2009-09-22 17:26:38] sjo...@php.net
If two or more of the libraries use __autoload, it won't work, and there is
nothing anybody can do about it.
If all of the libraries use spl_autoload_register, it works as it should.
If one of the libraries uses __autoload and others use spl_autoload_register,
it is the task of the library that uses spl_autoload_register to register
__autoload as well, like this:
if (function_exists("__autoload")) spl_autoload_register("__autoload");
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
https://bugs.php.net/bug.php?id=49618
--
Edit this bug report at https://bugs.php.net/bug.php?id=49618&edit=1
Req #53810 [Com]: Phar::mount() Entire Directory
Edit report at https://bugs.php.net/bug.php?id=53810&edit=1
ID: 53810
Comment by: staff at pro-unreal dot de
Reported by:panman at traileyes dot com
Summary:Phar::mount() Entire Directory
Status: Open
Type: Feature/Change Request
Package:PHAR related
Operating System: Win 7 32 bit
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Hi,
Mounting directories works but you have an error in your stub. Any
initialization should be called before Phar::webPhar() unless you want it on
CLI only.
What indeed doesn't work is mounting to files/directories that already exists
inside the phar.
Change make.php to the following:
addFile('list.php');
$p->setStub('getMessage();
}
?>
Previous Comments:
[2011-01-22 08:59:32] panman at traileyes dot com
Another nice feature that would go along with this is the ability to merge a
directory with an existing Phar directory. This way users could make their own
modules that would then act like it is apart of the Phar. I know this can be
done on an individual file basis but there may be files scatter throughout
several folders and just mounting the one folder would be nice. Of course there
would be some kind of conflict checker, maybe user option to use the internal
or mounted files.
[2011-01-22 05:12:45] panman at traileyes dot com
Description:
It would be _very_ nice to be able to mount an external directory somewhere in
the Phar. That way if there are many files that need to be included they don't
need to each be Phar::mount()'ed.
Note that all sub files and folders should also be in directory listings and
available through the Web. Bugs 53809 and 53801.
The directory structure should be as follows for the test below:
make.php = In the test script below
list.php = In the test script below
ext/page1.html = Page 1
ext/page2.html = Page 2
Test script:
---
addFile('list.php');
$p->setStub('getMessage();
}
?>
\r\n";
echo 'Exists: ' . (file_exists($path) ? 'Yes' : 'No') . "\r\n";
echo "Listing...\r\n";
foreach (new DirectoryIterator($path) as $file) {
if ($file->isDot()) continue;
echo $file->getFilename() . "\r\n";
}
echo "...done listing\r\n";
?>
Expected result:
Visiting: make.php
Done making test.phar
Visiting: test.phar/list.php
Path: phar://test.phar/ext
Exists: Yes
Listing...
page1.html
page2.html
...done listing
Visiting: test.phar/ext/page1.html
Page 1
Actual result:
--
Visiting: make.php
Done making test.phar
Visiting: test.phar/list.php
Path: phar://test.phar/ext
Exists: No
Listing...
Visiting: test.phar/ext/page1.html
404 - File /ext/page1.html Not Found
--
Edit this bug report at https://bugs.php.net/bug.php?id=53810&edit=1
[PHP-BUG] Req #53065 [NEW]: Allow spl_autoload to be case sensitive on *nix
From: Operating system: Ubuntu Linux 10.04 PHP version: 5.3.3 Package: SPL related Bug Type: Feature/Change Request Bug description:Allow spl_autoload to be case sensitive on *nix Description: I Opened This because #48129 is set to "won't fix". But this affects major frameworks i.e. (ZendFramework, FLOW3).It would be nice to tell spl_autoload() not to lowercase all filenames so that these framworks can benefit from its performance. To stay backwards compatible this could be done via php.ini or a function call. I would suggest spl_autoload_casesensitive in php.ini or a method spl_autoload_casesensitive(bool $flag); Another more compatible option could be handling this inside of spl_autoload(). Check for unmodified case first (i.e. Zend/Db/Adapter/Abstract.php) and if this is not available try lowercased (i.e. zend/db/adapter/abstract.php) This Solutions won't break BC! Test script: --- http://bugs.php.net/bug.php?id=53065&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53065&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53065&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53065&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53065&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53065&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53065&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53065&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53065&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53065&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53065&r=support Expected behavior: http://bugs.php.net/fix.php?id=53065&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53065&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53065&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53065&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53065&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53065&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53065&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53065&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53065&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53065&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53065&r=mysqlcfg
