i installed the xhprof profiling extension for php
Everything is fine except for the callgraph.php file, it returns:
failed to shell execute cmd=" dot -Tpng"
so i checked and the dot utility wasn't installed, so i installed it.
it appears to be running fine from the command line so i ran the scritp again, same error:
failed to shell execute cmd=" dot -Tpng"
the xhprof documentation states:
the callgraph image visualization ([View Callgraph]) feature relies on the presence of Graphviz "dot" utility in your path.
but i don't understand what i need to do now, specifically the "utility in your path" part
Any help appreciated, thanks guys
If you want graphing functions for xhprof run next command in terminal:
sudo apt-get install graphviz
When I enable error_reporting, I see there are some configuration variable are missing:
function xhprof_generate_image_by_dot($dot_script, $type) {
// get config => yep really dirty - but unobstrusive
global $_xhprof;
$errorFile = $_xhprof['dot_errfile'];
$tmpDirectory = $_xhprof['dot_tempdir'];
$dotBinary = $_xhprof['dot_binary'];
After add the following lines to xhprof_lib/config.php, it works
$_xhprof['dot_errfile'] = '/home/peniel/var/log/xhprof/error.log';
$_xhprof['dot_tempdir'] = '/home/peniel/var/log/xhprof';
$_xhprof['dot_binary'] = '/usr/bin/dot';
If you have installed graphviz this error also will occure because of the security restrictions. Some functions may be disabled. So, see your logs for some php warnings.
For example:
PHP Warning: proc_open() has been disabled for security reasons in /usr/share/php/xhprof_lib/utils/callgraph_utils.php on line 112
You need to configure php.ini or security.ini parameter "disable_functions".
Having the utility "in your path" means that it can be located by the environment variable PATH. This environment variables contains directories where the shell looks for binaries that you run without an explicit path.
Let's say the full path to dot is /opt/foo/bin/dot. Then you want to modify your PATH environment variable this way:
PATH=${PATH}:/opt/foo/bin
In my case this was caused simply because graphviz was not installed. You can check with which dot or locate graphviz on the command line.
steps for fast fix the issue if you have Graphviz and still getting error:
run "which dot"
/usr/local/bin/dot
open xhprof_lib/utils/callgraph_utils.php line 110
replace "dot" by "/usr/local/bin/dot" (or path you have)
Related
I have updated windows today and now when I use the command line and type PHP nothing returns. tried various PHP commands, nothing, not even an error or response. blank.
I had the correct path in the environment variables. Tried to change to another PHP version and even tried removing the path from environment variables but still returns empty!
It doesn't even say that "PHP" is not recognized although I removed the environment variable!!
I have no clue how to solve this.
If you are not passing extra parameters when you call it from command line, that´s how it supposed to work.
Try running:
php --help (to see all options from command line)
Also, to make sure it is running try to do this:
php -v (to check version)
php -F filename.php
The last one should run your php file.
I had the same challenge.
Here's a solution:
Use a standard terminal window (instead of Powershell).
Try php -v again.
IF you get an error mentioning VCRUNTIME140.dll
THEN you need to install run-time components that are required to run C++ applications built using Visual Studio 2015 here: https://www.microsoft.com/en-us/download/details.aspx?id=48145
So I have a huge list of text files inside a folder that I must process using a PHP script, and if processing is successful, I need to discard the file. However I only want to attempt 3 times each file, at most. If after the 3rd attempt it fails, I'll discard the file regardless.
So after doing some research I learned about Linux extended file attributes, and that seemed to be a viable way of keeping a counter in each file by means of an extended attribute.
Further research told me PHP supports this with a Pear package named xattr. I then installed the required libattr extension by running this command line (This is an Ubuntu 12.04 system by the way):
sudo apt-get install libattr1-dev
That worked fine. I then installed Pear xattr with:
sudo pecl -v install xattr
Which also succeeded and it indicated I had to add this line to php.ini:
extension=xattr.so
Which I also did and then restarted Apache. But when I attempted to use any of the xattr commands in PHP I always get this:
Call to undefined function xattr_supported()...
I checked phpinfo() and it indicates xattr support is enabled....
So what am I missing here? Shouldn't xattr_supported() at least return a boolean indicating whether extended attributes are supported by the file system or not? Or, is there any other way I can write random data to a plain text file without altering its contents?
Thanks in advance.
I have added this line PATH DEFAULT=${PATH}:~/bin/ to the ~/.pam_environment
This allows me to call ffmpeg from command line without path which is obviously in ~/bin/ dir so everything works fine as long as im ussing command line.
But if try to run the exact same command from php all i get is sh: ffmpeg: not found
And the code is
shell_exec("ffmpeg 2>&1");
So from my very little experiance with linux (in this case Ubuntu to be specific) i guess apache has no access to pam_environment or ~/bin
What can i do to make this work?
look at the output of phpinfo(), it has a section with all environment variables it sees. then look at your webserver configuration, maybe it's sanitizing the environment, or maybe the init script which starts your webserver does it.
and is the account the webserver is running under using PAM at all?
I'm currently developing a couple of plugins for Sublime Text 2 on OS X and I would like to make them cross platform, meaning I have to find out if and where php.exe is installed.
Right now I call /usr/bin/php in Python, which obviously works only on OS X and Linux:
phppath = '/usr/bin/php'<br>
pluginpath = sublime.packages_path() + '/HtmlTidy/tidy.php'<br>
retval = os.system( '%s "%s"' % ( phppath, scriptpath ) )
But on Windows, there seems to be no definitive default path for php.exe. The more I googled for it, the more possibilities showed up. So far I think I would have to check each of the following paths for existence:
c:\php\php.exe
c:\php5\php.exe
c:\windows\php.exe
c:\program files\php\php.exe
c:\wamp\bin\php\php5\php.exe
c:\xampp\php\php.exe
That's already quite a collection, but what I'm asking for is either a complete list covering all possibilities - or another way to figure it out that should be as robust as checking each possible path.
So if you have php.exe installed in some place other than these, please leave a comment with your path and I will add it to the list above.
Besides, there seems to be php.exe and php-cli.exe. I guess it would be OK to loop through each possible path. Check first for php-cli.exe, check for php.exe, and take the first match. Is that correct or is there a better practice?
If the user has added PHP's bin folder to the system PATH, then you should just be able to try and execute php -v to check that it's present.
If you want to obtain the full path to the PHP executable and the target system is Windows Server 2003 or later (so Windows Vista, and Windows 7) then you could use the WHERE command, i.e.:
C:\> where php.exe
C:\Program Files (x86)\WAMP\bin\php\php5.3.5\php.exe
Also see possibly related question: Is there an equivalent of 'which' on the Windows command line?.
If you are really desperate to find any file on the user's computer, you could try executing the equivalent of a find - but it's going to be slooow!
C: && cd \ && dir /s /b php.exe
On powershell or commad prompt
php -r "echo PHP_VERSION;" gives the version
See other PHP constantas:
https://www.php.net/manual/es/reserved.constants.php
to answer your question
php -r "echo PHP_BINARY;" gives the full path to php.exe
if needed, to remove the php.exe
php -r "echo str_replace('php.exe', '', PHP_BINARY);"
From PHP 5.4 and later, you can use the PHP_BINARY constant.
Use:
C:\xampp\php\php.exe
It should work if your XAMPP instance is on D: or E:. You change it accordingly from C:.
I found a way for you to find out where the php.exe is stored. In C:, click the search bar and search for "php.exe". Then, there will appear an application called php and click it. Then, cmd will open and in the cmd tab it will say php.exe at the end. That's where your php.exe is and you can put the link address of the file in VS Code.
Try
echo PHP_BINDIR;
It works. I tested it on macOS as with PHP 5.6.
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.