zf tool & PHPunit not recognised in include_path - php

I've be struggling with this for a while.
When using the zf tool included in the Zend Framework 1.11 to both create projects and actions and so on, I always get the notice that PHPUnit was not found in the include path and hence the test have not automatically been created. I know that this is only a notice and not an error however I would like it to work.
I am using OS X 10.7 and MAMP, my include path in MAMP is as follows:
include_path = ".:/Applications/MAMP/bin/php/php5.3.6/lib/php:/Applications/MAMP/bin/php/php5.3.6/lib/php/PHPUnit"
The only hint of the problem I have found so far on the internet is that the zf tool is using the natively installed php and include path and hence not noticing the PHPUnit.
I suppose that I could find the php.ini file and add the PHPUnit to it's include path but it feels a little bit of a hack.
Is there away to "prioritise" php installs?
Thank you for you help.
Al

I have finally found the answer at http://wiki.dreamhost.com/Zend_framework
Basically follow Step 5.
Replace
# find php: pear first, command -v second, straight up php lastly
if test "#php_bin#" != '#'php_bin'#'; then
PHP_BIN="#php_bin#"
elif command -v php 1>/dev/null 2>/dev/null; then
PHP_BIN=`command -v php`
else
PHP_BIN=php
fi
with
PHP_BIN=/Applications/MAMP/bin/php/php5.3.6/bin/php
Thank for your help anyway.

Related

Laravel and Mamp Localhost Error 500 Mac

So after a fresh install of laravel (v5.4) and using Mamp as my local server I just get (in chrome)
The localhost page isn’t working
localhost is currently unable to handle this request.
HTTP ERROR 500
I've tried countless things like changing permissions on storage or everything within the laravel directory.
Done composer update/install in the directory.
I'm running PHP v7.0.12 on my Mac (10.11.6). Cant think of anything else that would be causing this?
If I create another directory which a simple index.php with '' it loads absolutely fine so what is causing an issue with laravel?
Here's pics of my mamp setup
http://i.imgur.com/xT3mMZO.png
http://i.imgur.com/ddz9uij.png
Open up terminal and type:
tail -n 20 /Applications/MAMP/logs/php_error.log
This may give you some clue as to what is going on.
Hope this helps, happy coding :)
I just joined stackoverflow yesterday so I do not have enough reputation to comment. I write an answer here.
here is the short answer:
run :
PHP_VERSION=`ls /Applications/MAMP/bin/php/ | sort -n | tail -1`
echo "export PATH=/Applications/MAMP/bin/php/${PHP_VERSION}/bin:$PATH" >> .bash_profile
source ~/.bash_profile
check your php version by running php -v. close the terminal. Open another terminal and check php version again.if you see php 5 again then there are 2 possibilities:
First: you added the /path/to/php7 after /path/to/php5 and php 5 is loaded first.
Second: system loads another bash file first which your php 5 path is mentioned in it. I know that this sounds confusing having several bash file but it is. Please search for other files like bashrc or similars.
This is the long answer for anyone else:
first of all, if you are on mac, I highly suggest you to use valet to get rid of all these things.
But regarding the problem:
As you already noted that it is not a laravel issue. the php version that your machine uses is under the min required version by laravel. You have 2 versions of php at the moment. MacOs is shipped with php installed on that. I think it is the same php 5.5.36 that is making problem for you. Since Laravel 5.4, you need to use PHP >= 5.6.4.
Although you have installed parallel php 7 on your machine, you need also to check which php your machine is reading from by running which php. after that remember to add your path to php 7 installed to bash_profile or other bash files on your mac(you can have 4 or 5 bash files).
Considering you have only one bash file named as bash_profile and you are going to export the path to your php 7 to bash profile, If you run following command, that appends the path to the end of file
PHP_VERSION=`ls /Applications/MAMP/bin/php/ | sort -n | tail -1`
echo "export PATH=/Applications/MAMP/bin/php/${PHP_VERSION}/bin:$PATH" >> .bash_profile
remember to use source ~/.bash_profile in order to make changes effected.
Alternatively you can open the bash_profile file in your text editor by running:
open -a /Applications/TextEdit.app ~/.bash_profile
and add the path manually before the /path/to/php5 path.
finally you must check your php version by running php -v.
close the terminal. Open another terminal and check php version again. If you see php 7 then you are all fine. But if you see php 5 again then there are 2 possibilities:
First: you added the /path/to/php7 after /path/to/php5 and php 5 is loaded first.
Second: system loads another bash file first which your php 5 path is mentioned in it. I know that this sounds confusing having several bash file but it is. Please search for other files like bashrc or similars.

How to debug PHP CLI scripts from the CLI

Does anybody know how to debug CLI PHP scripts from the CLI?!? I don't want to debug a PHP web page - I don't have a PHP web page. I don't want to debug a remote script either - I'm running/debugging right here on this system. I don't want to (at this time) try to get some IDE (Eclipse, PhpStorm or whatever) to debug a CLI PHP rather I just want to debug some PHP CLI script at the Linux command line itself. In Perl this would be simply perl -d <script.pl> <options>. Debugging a script, to me, is not figuring out compile errors or other simple things. To me it's setting break points, running code, examine the contents of variables and being able to arbitrarily execute or eval ('<php code>') at the debugger.
Sure later I'd like to configure this into my IDE of choice (at this time this is Eclipse) but I have not managed to get that working. Debugging from the CLI a PHP CLI script would be a good start for me.
Thanks.
I don't know why I'm limited to a character count when posting a comment. Perhaps I can add more text here.
Here's what I have tried in order to use xdebug and/or Zend debugger with Eclipse:
Base Eclipse version Mars.1 Release 4.5.
Eclipse PDT UI Plugin version 3.7.0.2015112
Tried installing xdebug using pecl install xdebug. Says I need to add "zend_extension=xdebug.so" to php.ini. Really? Which php.ini? I have several:
Andromeda:sudo find / -xdev -name php.ini
/etc/php5/cli/php.ini
/etc/php5/apache2/php.in
/opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php53/php.ini
/opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php.ini
/opt/eclipse/plugins/com.zend.php.debug.debugger.php56.linux.x86_64_13.0.1.v20151112-2045/resources/php56/php.ini
Andromeda:
I put the zend_extension thing in both /etc/php5/cli/php.ini and /etc/php5/apache2/php.ini. Made a phpinfo.php page and I see Xdebug in there (yea!). Configure a Debug Configuration in Eclipse to use xdebug and try to debug:
Launching renameUser has encountered a problem. An internal error occurred during "Launching renameUser" java.lang.NullPointerException.
Oh goodie...
I had also installed the Zend Debugger and added the following to those same two php.ini files:
zend_extension=/usr/lib/php5/20121212/ZendDebugger.so
zend_debugger.allow_hosts=127.0.0.1/32, 192.168.0.0/16
zend_debugger.expose_remotely=always
Changed debug configuration to use Zend Debugger and attempted to debug. Received:
Error launching 'renameUser' The debug session could not be started. Please make sure that the debugger is properly configured as a php.ini directive.
Restarted Eclipse and now the debugger attempts to run but simply terminates with a 255 exit value attempting to run /opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php-cgi. Why it's runnign php-cgi is beyond me. I said this was a CLI not a CGI. In any event I get the following when trying to run this from the command line:
Andromeda:/opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php-cgi
/opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php-cgi: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory
Found a libiconv.so.2 in /opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/lib and set LD_LIBRARY_PATH to include that but this just fails to launch the debugger at all stating to make sure that the debugger is properly configured as a php.ini directive... UGH!
Other odd stuff:
When Eclipse starts up it fails to open my RSE based project thus displaying edit buffers from the last run as empty
Eclipse will no longer exit! Select File: Exit. Nothing happens. Click on the X in the title bar - nothing happens. Now I have to kill it to close it!
When debugging on the command line you need to tell PHP you want to debug also
http://xdebug.org/docs/remote
says
export XDEBUG_CONFIG="idekey=session_name"
php myscript.php
assuming xdebug is enabled (it doesnt matter which .ini file its in, but there is a standard place per OS for this, usually in a conf.d folder called xdebug.ini which is auto included)
This allows you to debug a cmdline script.
Personally I use Vim with Vdebug extention (xdebug for vim) to debug and nothing other than a command line is needed
What worked for me was using dephpugger. I found the steps to get CLI debugging working here:
https://hackernoon.com/how-debug-php-applications-with-dephpugger-98cc234d917c
I had previously installed xdebug and tried out exussum's answer.
The steps I followed are included here for completeness.
Install dephpugger:
composer global require “tacnoman/dephpugger”:”dev-master”
Put dephpugger on the path:
export PATH=$PATH:$HOME/.composer/vendor/bin
make sure to include in the php file at the breakpoint:
xdebug_break();
open up 2 terminal instances. In one run:
dephpugger debug
In the other run
dephpugger cli /path/file.php
replacing /path/file.php with the path to your file. if you need command line arguments to the php script put the path and arguments in quotes. It still seems a little hacky. I think the real trick is to write in a language that has a better debugger built in.
exussums answer works for me.
In addition I have the following in /etc/php/7.0/cli/conf.d/20-xdebug.ini
zend_extension=xdebug.so
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_enable=true
#xdebug.remote_enable=false
And I had to do this: https://github.com/vim-vdebug/vdebug/issues/363
Being able to set break points in a PHP script requires some kind of debugger extension being loaded, either XDebug or Zend Debugger.
And then you need some kind of interface to this debugger to make your wishes about break points known. I am unfamiliar with the Perl debugging, but I haven't heard about any PHP CLI based debugging - it is always taking place in an IDE that is able to handle the debugging protocol of one of the extensions.
Of course there is the good old var_dump();die('hi'); debugging, but this does not include continuing code execution after the script ended. ;)

PHP from source - Questions about Extension-Folder and Interaction with existing repo-version

As a Linux beginner I'm currently a bit confused building my own PHP from source.
I have a Ubuntu with a LAMP-Stack where all packages comes from a Repository.
(PHP as FastCGI)
Now I'm trying to set up a second PHP-Version and actually it works well but I have a few questions.
First of all some specs:
Ubuntu 10.04 (I need this older Version)
PHP 5.3.2-1ubuntu4.2.5 (Repo)
For my own PHP-Version I use the following "./configure" parameters (Reduced to the essential):
--prefix=/opt/php5310
--with-config-file-path=/opt/php5310/etc
--with-config-file-scan-dir=/opt/php5310/conf.d
--with-libdir=lib64
--with-mysql=/usr/bin/mysql
...
First of all executing "sudo make test" show up a few failed tests (about 10-14). Unfortunately I can't find any information what I have to do or what excactly goes wrong but "sudo make install" works nevertheless.
Is it normal that not all tests passed?
Then I noticed (phpinfo) the "imagick" extension was not loaded.
Looking at the "extension_dir" shows why.
On the Repo-Version:
extension_dir = /usr/lib/php5/20090626
On my own Version:
extension_dir = /opt/php5310/lib/php/extensions/no-debug-non-zts-20090626
(This folder doesn't even exist)
When I put this inside the php.ini:
extension_dir = /usr/lib/php5/20090626
It's working but is it the right way or just a creepy workaround?
And what about "--with-libdir=lib64" doesn't it belong to "extension_dir"?
On my System /usr/lib64 is a symlink to /usr/lib.
And last but not least my Repo-Version has a folder "/etc/php5/cgi/conf.d" with many ".ini" files e.g. "curl.ini", "gd.ini" and so on.
My Solution was:
"--with-config-file-scan-dir=/opt/php5310/conf.d
And then create the "conf.d" Folder and copy everthing from "/etc/php5/cgi/conf.d" to "/opt/php5310/conf.d" to be not dependent on the PHP Repo-Version.
Would this be a correct solution for multiple PHP-Versions or should it be a symlink or
"--with-config-file-scan-dir=/etc/php5/cgi/conf.d
Thank you for your help
Failing tests generally means failing functionality. Of course, for something as large as PHP you may never touch that functionality. It may be that your best bet here is to search for the names of the tests which failed to see if anyone has had the same issue (and how to fix it or disable the functionality), and to find the source of the tests in PHP and understand why they failed.

Google App Engine PHP on windows

I'm trying to get started with using Google app engine with PHP (on Windows 7) and have been trying to follow the helloworld example here.
Problem I am having is in starting the webserver. Whenever I try to run it I get the error
dev_appserver.py: error: too few arguments
I'm typing the following at the command line:
google_appengine\dev_appserver.py --php_executable_path=c:\php\php-cgi c:\appengine\helloworld\
Any suggestions as to what I am doing wrong?
Cheers
Use quotes for arguments.
google_appengine\dev_appserver.py --php_executable_path="c:\php\php-cgi" "c:\appengine\helloworld"
Or use slashes instead of backslashes as directory separator:
google_appengine\dev_appserver.py --php_executable_path=c:/php/php-cgi c:/appengine/helloworld
For best results combine both methods ;)
So I was running into this issue, and tried every permutation of paths using quotes, and switching to the directory where appengine SDK was installed etc. Finally I realized that Python was running the script but it wasn't including the command line arguments being passed in. So I had to manually call python like this:
c:\<python_path>\python <sdk_path>/dev_appserver.py --php_executable_path=c:/php/php-cgi.exe helloworld/
I'm not a python guy so I don't know why the command line arguments got stripped, but I've had this issue with other applications in Windows 7
This answer solved the issue for me.
Just to clarify it a bit, here is how the value under
HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command
should look in Windows regedit tool.
And it should be the same as the value under this path:
HKEY_CLASSES_ROOT\Python.File\shell\open\command
Solution tested on environment: Python 2.7.5 on Windows 7 (Home Premium) x64.
In fact I had this problem not with PHP App Engine but with Go App Engine. However, it is apparently not App Engine, but rather a Python+Windows issue.
I'm using Windows 7 too.
Here it's my code tested:
dev_appserver.py --php_executable=c:/php/php-cgi.exe c:/appengine/helloworld
Notice! I'm inside google appengine directory.
For example if you installed the SDK in C:
Write first cd google_appengine hit enter, and then use the upper code.
You have to either: give full path to dev_appserver.py
or
cd into the directory where you instaled it
If You followed example to the letter You would have instaled it in C:/{username}/something directory
and the call would be then something/dev_appserver.py as stated in example in helloworld!
Hovever - the example have one error in it: the directory they are proposing is not the same they are using in example call! Thats why make sure the "sometinhg" directory is the same in call as used to instal app engine
after I moved everything to c:\ to simplify the paths I ended up calling it from the dos command prompt like this
C:>\Python27\python C:/google_appengine/dev_appserver.py --php_executable_path=
C:/php/php-cgi.exe c:/google_appengine/helloworld/
And it works!
is the python command line tool the way we should be running this stuff?

illegal command error code 127 in php exec function

I am using this php code:
exec("unrar e file.rar",$ret,$code);
and getting an error code of illegal command ie 127 ... but when I am using this command through ssh its working ... because unrar is installed on the server ... so can anyone guess why exec is not doing the right stuff?
Try using the direct path of the application (/usr/bin/unrar of whatever), it sounds like php can't find the application.
If you have chrooted apache and php, you will also want to put /bin/sh into the chrooted environment. Otherwise, the exec() or passthru() will not function properly, and will produce error code 127, file not found.
Since this comes up as a top answer in google, I wanted to share my fix:
The simple fix I had was to disable safe_mode in the php.ini file
; Safe Mode
; http://www.php.net/manual/en/ini.sect.safe-mode.php#ini.safe-mode
safe_mode = Off
thanx all for your response!!
I tried this
//somedir is inside the directory where php file is
chdir("somedir");
exec("/home/username/bin/unrar e /home/path/to/dir/file.rar");
and now it returned no exit code ... oher commands are doing file .. i tried mkdir etc .. :s
Just in case somebody else still gets this problem, take a look at the post here:
http://gallery.menalto.com/node/2639#comment-8638
Quote:
I found the problem. The problem was my security-paranoid OpenBSD. When upgrading from 3.1 to 3.2 they added:
Apache runs chroot'd by default. To disable this, see the new -u option.
The chroot prevented Apache from accessing anything outside of a directory, so I moved everything into the apache directory including netpbm. Everything was accessible and executable, but I guess it was still in some sort of "safe mode" because the exec() always returned 127.
Anyway, running httpd with the -u option went back to the less secure non chroot'd apache startup, which allowed the exec() to work again.
ohkiee guyz thanx ... and yes there might be some errors with $PATH ... but with given full path its working :)
exec("/home/user/bin/unrar e /home/user/xxx/yyy/file.rar");
I did not find the solution for my problem of the same type so sharing what was the cause of it in my Linux setup.
For whatever reason I needed an apache module loaded before other modules and so apache was started with LD_PRELOAD. As exec inherits the environment of the parent process LD_PRELOAD was used for starting the exec-ed program (through sh). Now the preloaded module uses some bindings to apache functions and of course they are not to be present in sh. The result of the php exec was an exit status of 127. The solution was to have in my php file a putenv("LD_PRELOAD") that gets executed before any exec calls.

Categories