I'm seeing an old path showing up on phpinfo under PATH. I've looked EVERYWHERE for it. Cannot figure out what's setting that path...
Checked php.ini, the apache conf files, there's no .htaccess, nothing in the index.php. Unless the old path is cached somehow somewhere, I cannot figure out where it's coming from.
I'm using Zend Server CE on Max OSX Leopard.
Did I overlook something? Any other place I should check for path being set?
UPDATE:
I rebooted the machine figuring that might remove the phantom path, and it did!
Wonder if this helps?
See: $PATH environment variable for apache2 on mac
Talks about checking /System/Library/LaunchDaemons/org.apache.httpd.plist
PATH can be set by a variety of files. For example, on Linux (and I would imagine mac which is also BSD) it is set by the init proc on startup. Apache may never overwrite this path, so it might just be using the default startup path set by init or your default user profile. You can probably overwrite it for apache if necessary with /System/Library/LaunchDaemons/org.apache.httpd.plist, or wherever apache is installed to.
As an example, when you run php --info as another user, what is PATH set to?
PATH is an environmental variable and does not have anything to do with PHP or Apache.
Here is an article: http://mactip.blogspot.com/2004/04/setting-environment-variables.html
Related
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.
I'm having a weird situation here.
I'm trying create a PDO object, like this:
$dbh = new PDO('mysql:host='.$hostname.';dbname='.$dbname,$username, $password);
I have rewriting ON in my .htaccess file. when I try to run the script using a URL that will trigger a rewrite rule, it shows me the following error:
Fatal error: Class 'PDO' not found
I have a exception rewrite rule for a directory where the script is, named PHP, like this:
RewriteRule ^(php)($|/) - [L]
if I run the scripting directly from the directory, it runs normally with no erros.
I don't know why this is happening. any clues?
Thank you
Edit: Ok, I saw I've misinterpreted your question a bit, but I still think there is something wrong about the php.ini path. Could you check the phpinfo() output of both web calls. The basic idea of the answer keeps the same as stated below (replace CLI with the second web call ;))
OLD ANSWER
Assuming, that you have one of the more common linux distributions (ubuntu, debian, suse, etc), you might have two (or more) php.ini files. One that is pulled when using the webserver module (which seems to be an apache) and one that is used for the cli env. php supports up to one php.ini per SAPI.
In newer debian and ubuntu systems php extensions are linked in the same manner as the sites-available/enabled in the apache config.
If you have a self compiled php look for a php-cli.ini at the common location for the php.ini (which is /usr/local/share/php by default). If a php-cli.ini is present it will be used instead of the php.ini for cli commands.
(Manual Reference: http://de2.php.net/manual/en/configuration.file.php)
How to find out:
Get the phpinfo() output for the INFO_GENERAL section from you webserver. To achieve this, create a simple php file in a web-accessible directory (e.g. the DocumentRoot). Remember to delete it after you got the information you need! Please adjust the '/var/www' to something that matches your config.
$> echo '<?php phpinfo(INFO_GENERAL);' > /var/www/info.php
Now go to your browser and open http://your.host.name/info.php and look for the config property "Configuration File (php.ini) Path". Note this somewhere or just leave the page open for later reference.
On your cli this is also quite easy. The example below is a snip from my shell.
mmueller#bsd ~$ php -i | grep ini
Configuration File (php.ini) Path => /usr/local/etc/php/5.5
Loaded Configuration File => /usr/local/etc/php/5.5/php.ini
[... omitted the tail]
Compare the two paths and see if they are different.
To see why this happens, please take a look at the 'Configure Command' section. You mighty find three important configure arguments. Those three influence where php looks for it's configuration.
'--sysconfdir=/usr/local/etc/php/5.5'
'--with-config-file-path=/usr/local/etc/php/5.5'
'--with-config-file-scan-dir=/usr/local/etc/php/5.5/conf.d'
If you want to ensure the same configuration, you can do one of the following things:
Just add extension=pdo_mysql to the webserver version and see if that is enough
Remove the additional CLI config (if present), this will make php use the php.ini for all SAPIs (make a backup of the file before you do that!). Then you need to merge the rules into the php.ini that you need. (In your case there seems to be an extension=pdo_mysql missing)
Check the webserver php.ini for anything that you do not want to have in the cli version, then copy the webserver php.ini over the CLI php.ini (Do a backup first).
Delete the cli or webserver php.ini, symlink the other php.ini to the place of the deleted one. (not the best way, but I've seen that a lot on customer servers).
Solve it.
There was a empty php.ini in the public_html, I deleted it, and it worked.
thank u all
Normally google is my friend for these kind of newbie problems, and I'm pretty proud of myself learning as I go without really needing to ask any questions in terms of PHP stuff, but this one's got me stumped. Trying to install a version of PEAR that supersedes my host's copy, which is hideously outdated. Apparently "pear's binary (bin) directory should be in your PATH variable." I don't know what that means or how to edit it, and supplementary to that, wether that will actually solve my problem of an outdated version of pear being on my root server. Any advice in either of these areas would be greatly welcomed, thank you.
Actually, they are talking about the OS's PATH environment variable, not PHP's include path (binaries [bin] are run by the OS, not parsed by PHP) Unfortunately, since you are in a shared hosting environment, you cannot change this environment variable in a permanent fashion. If you do have shell access though, you can modify your .profile file set the PATH variable.
You can use getenv() and putenv() to retrieve and set the PATH variable, but this will be reset on each script run.
That said, you do not need the PATH variables set to use PEAR. If you have a PEAR install on your development computer, you can upload the pear folder onto your host and modify the include_path at runtime to point to your own "install" using set_include_path()
$pearInstallPath = realpath('./pear/packages');
set_include_path('.' . PATH_SEPARATOR . $pearInstallPath);
The PATH variable that's being referred to doesn't actually have anything to do with PHP.
The PATH is the list of directories that your shell will look in to find a command you run on the command line. So, this is talking about making the shell find the right path when you run pear on the command line.
Assuming you're using bash, one way to change this is to add a line like
export PATH=/path/to/pear/bin:$PATH
to a .bash_profile or .profile file in your home directory.
Try this
getenv('PATH'); // for get PATH varibale
putenv('PATH=./'); // for set path variable
getenv, putenv
I'm a little bit confused about the Windows System %PATH% variable. When I ran the following script with both, php-cli and as a webpage delivered by apache, I get different output for the path variable.
// different output for php-cli and php executed by apache webserver
<?php
system('echo %PATH%');
?>
Where can I change the PATH variable that is in use with the apache webserver?
My system:
Win7 64bit
Zend Server Community Edition 5.0.4 (with Apache, not IIS)
Edit:
Sorry, I had to give you an example to understand the problem:
I wanted to exec the system('mysqldump .....') command or something like that. The point is, running the script from the command line works, because the MySQL bin path is in the system's path but running the script via webbrowser doesn't include the MySQL bin path in the system's path.
The web system's path is:
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;D:\Programme\Sysinternals;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Zend\ZendServer\bin
Bit the original system's path is much longer. My question is now, where is the system's path limited or where can I find the system's path settings for the web executed php script?
Try using the following instead,
echo getenv('PATH')
See at C:\Path\To\Zend\ZendServer\ZendEnablerConf.xml.
There is a path variable definied.
Environment variables are per-process in Windows; they are (usually) inherited from the parent process, with the top process setting PATH to the system-wide path plus the per-user path. Therefore, if you are running CLI version of PHP under your user account, the path will contain your user-defined path, while the Apache process running under a service account will get only the system-wide path.
You can set the system-wide path in System Properties (Control Panel\System and Maintenance\System), Advanced, Environment Variables. Or, I believe you can set the environment variable in Apache, e.g. using mod_env and the SetEnv directive.
I'm on a Windows machine. This seems like it should be unnecessary, but when I do it, everything suddenly works. Is there something wrong with my path? Do I need to add something to it to avoid having to copy DLLs?
Apache like any application will assume that the file is located in the same directory as the Current Directory path (check out http://en.wikipedia.org/wiki/Working_directory). If it's not there. The current working directory is USUALLY the same directory that httpd.exe (main executable) is in but it can actually be different if you do something like
C:\Apache2>bin\httpd.exe
In this case the Current Working directory is C:\Apache2 rather than C:\Apache2\bin.
If if the file isn't found there the application will naturally traverse the PATH environment variable. The PATH environment variable is a semi-colon or comma separate list of paths) to find the file.
Start -> Run -> Type "cmd.exe" and then in the Command Prompt type "echo %PATH%" to see the current path you have.
Finally, if the file wasn't found it will just error out.
As a tip you can actually track what files an application is trying to load and where they load them from by using Process Monitor. http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
I've used this tool to solve load DLL problems in Apache before and other applications as well. Just simply add a filter for the app you are running and have it only sniff out file reads.
I donot know the internals of MySQL and apache.
My thought is this. Internal of your application is using libmysql.dll. And it seems that path is not proper so it searches in PATH environmental variable. apache/bin will be there in PATH directory. So it is taking the dll from this path. If the dll is not present in that path I think it fails to load and hence fails.
EDIT: Added the solutions which were added in comments
Try rebooting your machine. I had the same issue with mysqlpp library. Path was pointing to mysql bin dir but it still couldnt find libmysql.dll – Daniel (Jan 26 at 6:55)
Apache might be running with credentials different from your own (almost certainly so if you're running it as a service.) Try placing the dirs in the SYSTEM path, not the USER path. – moocha (18 hours ago)