I'm trying to use the exec() PHP function on a system that run on HHVM.
Unfortunately, the command (even a simple echo) return an empty string, without any error. When I try the command inside terminal as root the output is correct.
PHP Safe mode is off, I guess this is a permission issue but I don't know how to solve it.
I've updated HHVM to 3.x, and it's now working like a charm.
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
I have a very strange problem.
I'm trying to make a program that executes shell_exec() in PHP with NMAP.
The problem comes when I put shell_exec("nmap --version"), because it returns me version 4.11, but when I put it directly on shell, it returns me version 7.01.
When using shell_exec you should always use the full path to the executable.
exec("fun.exe input/input.txt ");
I want to run an CUDA program in PHP,
the task is:
load data from an input.txt. (argument)
calculating.
write an output.txt.
and PHP read ouput.txt to do next task.
In server1(Apache ,Windows XP), it can run perfectly,
but in server2,3(Apache, Windows 7),the output is wrong.
The program doesn't crash and there's no any error message in the page,
it seems like something wrong during the execution.
Next I try exec the All CPU-side version (same calculation),server2,3 can run correctly.
If I exec the fun.exe(CUDA version) in server2,3 directly(double click or in command line),the program also run perfectly.
Any idea on why server2,3 can't run the program? Thanks.
First, try using the full path to the executable. Then the full path to the input file too.
If that doesn't work, then try modifying the file permissions (try with full 777 permissions, if that works then you know where your problem lies).
Try to use the entire path (windows version using backslash).
I have a program that returns a comma-separated string of numbers after doing some background processing. I intended to run this in symfony using shell_exec; however, all I get is NULL (revealed through a var_dump(). I tried the following debugging steps.
I ran the file (it's a PHP class) through a command-line lime unit test in Symfony - it works and gives the correct result there.
Just to check, I tried a simple command ls -l at the same place to see whether I would get anything. Again, I had the same problem - the var_dump in the browser showed NULL, but it worked through the command line.
What could be the problem? Are there restrictions on running shell_exec() in a browser?
EDIT: Just to clarify, shell_exec() commands work when I run them as standalone php scripts on the web server (for example, by putting them in my document root. They don't seem to be working under the symfony framework, for some reason.
I finally solved it, and it turned out to be something quite simple, and quite unrelated.
The shell command I was running was in this format: face_query -D args. I didn't realize that Apache would be executing PHP as user www-data and thus the program face_query wouldn't be in the PATH (the directory is actually ~/bin). Changing the program name to the full path of the program solved it.
I also gather from this that only commands which www-data has permission to execute can be run. In this case, www-data is in the same group as my user, but it might be a problem otherwise.
Have you tried using exec? Or one of the other variants. I am never sure of which one to use and always lump with exec.
http://uk.php.net/manual/en/function.exec.php
Is your web server running php in safe mode?
Note: This function is disabled when PHP is running in safe mode.
From: http://php.net/manual/en/function.shell-exec.php
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.