I'm trying to launch unoconv using exec in php. It works with apache2, but not with nginx.
I've already checked my php.ini and disable_functions not contain exec in both apache2 and nginx php.ini files.
I'm not familiar with unconv, but I've had a similar problem with porting my server from Apache to nginx and exec.
nginx + php-fpm have a bare minimal $PATH set compared to apache, and it's likely your unoconv is not on that path.
You could try modifying your PATH settings, but a better way would be to specify the absolute path of unoconv
You can find the absolute path by using
which unoconv
You should also re-direct the error output to stdout, so you can see exactly why unoconv isn't starting
exec("/path/to/unoconv -param0 -param1 2>&1", $output);
print_r($output); //this should give failure reason
Check out this post : PHP exec() does not run all commands
As said in this post :
The problem is that you're running notify-send from a service. Notify-send is a desktop-oriented program which interacts with the display. But nginx runs without being attached to a display.
Imagine, for example, that there are 3 people logged on to the computer at the same time, all with different displays. When notify-send runs, it wouldn't know which display to send the notification to.
Related
On a shared server with ffmpeg installed above the webspace. Example: /home/username/ffmpeg/ffmpeg which is the full address all the way down to the executable.
The problem is that php cannot find ffmpeg using the -verson option. We tried using mod rewrite to a php file in the public_html webspace which then includes the ffmpeg address above the webspace. But that did not work.
I have never dealt with ffmpeg installed this way, its always been installed in /usr/bin/ or /usr/local/bin .
is there a htaccess or php ini command to tell php where ffmpeg is installed?
how does php suppose to access ffmpeg installed in this way, it is installed as an alias?
Thanks so much :)
As php and ffmpeg are separate things, there's no guarantee that your host will allow php to run ffmpeg, however here are some things you can try:
You can check if web server's user (which php runs as) can "see" any ffmpeg executables in its path by running:
<?php echo shell_exec("which ffmpeg"); ?>
If the output is empty, ffmpeg isn't in the path of the web server's user. In this case you still might be able to run it, if you know the path of the executable.
Also if you run:
<?php phpinfo(); ?>
That will tell you if php is running in safe mode. If it is, your web host may have locked down php's ability to do potentially dangerous things such as executing shell commands.
Change Permission of binaries files (ffmpeg.exe and ffprobe.exe) to 0744.
See image sample here:
I had developped a shell script and I wanted to create an UI with it. I decided to use a web interface with a local server because I have few knowledges in HTML/PHP, more than QT or Java. I simply want that my html can run a shell script on my computer.
I have an Apache php server which I start in localhost with apachectl.
In /var/www/html/ I have a shell script and a test_web.php file which execute this script with exec('/var/www/html/test.sh')
In my html I have this:
<form method="POST" action="test_web.php?">
<input type="submit" value="Execute" name="exec">
</form>
If I click on Execute, it opens a new page where I see the output of echo commands from the script but it is not executed on the terminal as a standard script (like if the script is not executed on server side).
I want this script to be executed as started from the terminal.
Thank you for your help
As suggested by some commentators, you could use the Apache cgi features to be able to execute directly your test.sh file (1), but since you say you are using a Php enabled Apache server, you have an alternative and easier option with Php which you partially already tried (2). In both cases, you will need to take care of the permissions and ownership of the bash script, and its execution environment for it to produce the same results as on the command line (3).
1. CGI
CGI stands for Common Gateway Interface. It allows web servers to execute programs that are executable on the host, and interface with the web server. That is a protocol per se, and CGI can be used not only to execute programs, but also for creating dynamic sites. You could program a dynamic website in any language, provided the executable is programmed to receive data via stdin from the server and interpret the headers, decode any contents properly, and that the program can return proper dynamic data to the server via stdout, with proper headers, Content-type, etc.
There are libraries for helping in this task for many languages (for C, Perl has a CGI module in is Core Modules, etc., and even for Bash).
On Linux, to use CGI with Apache 2, you would need to make sure that your Apache configuration loads the required module for supporting it, and select the directory where your web server will be allowed to execute the programs:
# uncomment or add the directive for the module
LoadModule cgid_module modules/mod_cgid.so
# one way to allow the server to execute cgi programs is to
# set a ScriptAlias directive to a directory dedicated to CGI programs
ScriptAlias "/cgi-bin/" "/var/www/html/cgi-bin/"
You put your test.sh script in /var/www/html/cgi-bin/, and browser can be pointed to http://localhost/cgi-bin/test.sh to directly execute the script. There are other configurations possible, see this Apache CGI tuturial.
If you need to execute the Bash program and want your CGI to send anything to the browser, the first echo sent by the Bash script shall be the following output:
Content-type: text/html
followed by whatever dynamic html you want to produce.
2. Php
Really all these complications may not be necessary since you say you use a Php enabled Apache server, and since you probably do not want the Bash script to send html directly to the browser.
In that case, the shell_exec() command or backticks operator, will allow you to run your Bash script and obtain its output in a Php variable, and do whatever you want to do with it in Php.
You say you have tried using the exec command, which should work also, except that you get a status code in response, and not the program output.
If your execution command does not work at all, this may be because of permissions, ownership or execution environment issues.
3. Permissions, ownership and execution environment
Have a look at your Apache logs for errors produced by the exec or shell_exec commands.
The script needs to have execution permissions, and needs to be readable and executable by the web server.
For instance, on Debian, Apache web server runs as a user www-data, so a script would need to be owned and executable by that user:
chown www-data:www-data test.sh
chmod u+x test.sh
You can find the location of the Apache logs and the user and group under which the web server runs in your Apache configuration file by inspecting (as root) the results of:
apachectl -S
Another possible issue is the environment in which Apache will be running the script. That environment, may or not include the same environment variables, the $PATH will be different and may not include all directories available to a "normal" user executing the same script on the console.
Again, check for errors in the logs.
The most frequent cause for failure is a Bash command not found because it is not in the $PATH of the Apache process. The quick fix is then to change the script to prefix the command with its full path.
So, for instance, if your test.sh uses a program called validjson, open your terminal as a user that can execute the script without errors, and check where it is:
$ which validjson
validjson: /usr/local/bin/validjson
and instead of calling validjson in the script assuming it is in the $PATH, call it instead with its full path /usr/local/bin/validjson reported by the which command.
If you are calling other scripts or programs, they may have the same issues, check that until you have debugged the execution of your script.
In my local development environment, I have Apache and PHP installed on Windows 7. I'm calling 7-Zip from my PHP program with exec. I tried at first with
exec('7z a example.zip example.pdf');
but it didn't create the zip file. After checking the Apache error log, I found
'7z' is not recognized as an internal or external command, operable program or batch file.
After changing the exec to include the full path to 7-Zip.exe, it worked.
exec('"C:\\Program Files\\7-Zip\\7z" a example.zip example.pdf');
But C:\Program Files\7-Zip is included in my Windows system PATH. The same PHP code works from the command line without using the full path.
php -r "exec('7z a example.zip example.pdf');"
Why is it requiring the full path when I use it with Apache?
An important point which I neglected to include when I originally posted this question is that I am already able to use exec() to call other programs included in the Windows System PATH without referring to them by their full paths.
Another point which I did not mention originally because I did not realize its relevance was that 7-Zip had been added to the PATH only recently, and I had restarted the Apache service after adding it.
I've WAMP installed on windows 8 and after reading your question I decided to test a couple of things.
Running echo exec('whoami'); echoed:
nt authority\system
This confirms what #Barmar said, Apache isn't running under the same user as you, so, the PATH is different.
I decided to stop Apache and start it manually under the Administrator account.
Then I tried:
echo exec('whoami');
Which outputted:
computername\administrator
I assumed that now the exec would work with PATH and tried:
echo exec('adb'); //android adb tool is on my PATH
Surprisingly, despite the fact Apache was running with the same user as me, the PATH still didn't work. I've no idea why this is happening and if someone has a clue please comment below.
I managed to use the PATH (using the Administrator account) with the following code:
https://stackoverflow.com/users/171318/hek2mgl
$WshShell = new COM("WScript.Shell");
$oExec = $WshShell->Run("cmd /C 7z a example.zip example.pdf", 0); // 0 invisible / 1 visible
I didn't test the code below, but you can try setting the PATH under the Apache Service account (nt authority\system), and then use the command, i.e.:
echo exec('set PATH=%PATH%;C:/path/to/7z');
echo exec('7z a example.zip example.pdf');
I believe the path will still be valid between restarts.
Update:
this answer, may help you setting the PATH for the account nt authority\system.
The Local System user's personal environment variables are specified
at "HKEY_USERS.DEFAULT\Environment". The machine-wide environment
variables are specified at
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Environment". The former isn't really easily accessible from
anywhere except the registry, but the latter is accessible from the
"Environment Variables" dialog on the "Advanced" tab of the "System
Properties".
For future users, the correct way to set the Apache PATH is:
You can use setEnv in .htaccess or putenv in PHP code to set
$PATH
Credit goes to hek2mgl
I just figured out what was causing this problem. It was actually unrelated to my original assumption.
I remembered seeing PATH information in phpinfo(), so I looked at that. In the "Apache Environment" section it did show all of the PATH except the path to 7-Zip, which I had just added to the system PATH recently. So apparently it DOES seem to have access to that path, but it wasn't using the current version of it. Why not?
Normally I would think I had just forgotten to restart Apache after updating the path, but I'd restarted it repeatedly while trying to figure this out. But apparently restarting Apache does not refresh this value. I had to stop it and then start it. Then the 7-Zip path showed up in PATH in phpinfo, and I was able to change my program back to using plain 7z.
On Windows, to run the PHP web server from the command prompt I type:
php -s localhost:80800 -t public
And I get this error:
Could not open input file : localhost:8080
And yet cmd php test.php will echo the text. Why?
It was just the capital S.
php -S localhost:8888 -t public
Now I can see the page in a browser.
I had to cd to the right directory ...and public has an index.php file.
It will work without using XAMPP/WAMP or any other external server, as PHP has its own server inbuilt. You have done a mistake in typing s in php -s localhost:80800.
This command will work - php -S localhost:80800.
"s" in the command will be capital, not small...
You can not run localhost using native PHP. You need a web server like CAMP or WAMP and configure the port while installing this software.
It sounds like you are running PHP as a CLI (command-line interface).
As stated, there are WAMP stacks to install and configure. I would suggest looking online for one of the many tutorials. To install one, they will take you through the process as well as some of the advanced configuration to secure the installation from unwanted outside access.
PHP itself is not a web server, hence why you cannot just write php -s localhost:8080 -t public.
You will need to have a corresponding web server, e.g. Apache, and link this with your PHP, allowing PHP to process the files that Apache will serve on its server.
You may want to use XAMPP to do this, since it is an easy-to-use bundle for Apache, MySQL (a database system), and PHP.
Download it on its website.
try php -S localhost:8080 It's Will work but capital S not The Small one i mean
I was experimenting with shell_exec and commands, and I can't seem to get this work. Im using the php shell_exec() function and running a screen capture command to take a snapshot of the desktop. When running the script locally through coda, it works fine. Then i ran it through my installion of apache through htdocs, and it runs, yet it doesn't save the image anywhere? For browsers, do i need to change the directory at all? this is what my super simple script looks like. Is this even possible?
<?
$command = "screencapture -iWP ~/Random/test.png";
shell_exec($command);
?>
I don't currently have access to a Mac to test, but I'd be extremely surprised and more than a little concerned if that did work.
On the server, apache should be running under a different user ID to the logged in user, which means the attempt to grab the framebuffer should fail.
If it did at least write (or try to write) an image, then it will be ~/Random/test.png; e.g. if apache runs as a user called apache, the target filename is ~apache/Random/test.png
OSX is basically UNIX, and a key feature of UNIX-like operating systems is security. The video framebuffer should only be accessible to processes running under the UID of the logged in user (or root). Daemon processes like apache httpd should be running under their own, non-root UID.
You probably have to specify the full path of the executable. Also, specifying the full path of the output PNG would help too because they're different users.
Run the command
which screencapture
To find the path that the executable is located in. The output file must be in a writable directory for the user that apache is running under (usually apache). You can check the user that apache is running under by looking in the apache configuration, or just running "top" (as root).
Hope that helps.