Cant access environment variables in php - php

Im having issues accessing OS environment variables in php
I have apache/php installed on a centos 6.3 image
in httpd.conf mod mod_env.so is loaded
in php.ini I have set variables_order = "EGPCS"
restarted httpd (many times)
in shell if I type "env" I get
DB_PORT_28017_TCP_PROTO=tcp
HOSTNAME=c6188a8bd77f
DB_NAME=/rockmongo/db
DB_PORT_27017_TCP=tcp://172.17.0.36:27017
TERM=xterm
DB_PORT_28017_TCP_PORT=28017
DB_PORT=tcp://172.17.0.36:27017
DB_PORT_27017_TCP_PORT=27017
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/etc/php.d
DB_PORT_27017_TCP_PROTO=tcp
DB_PORT_28017_TCP_ADDR=172.17.0.36
DB_PORT_28017_TCP=tcp://172.17.0.36:28017
SHLVL=1
HOME=/
DB_PORT_27017_TCP_ADDR=172.17.0.36
container=lxc
_=/usr/bin/env
OLDPWD=/etc
which has the variables im after, however if I execute print_r($_ENV); in php I get
Array ( [TERM] => xterm [PATH] => /sbin:/usr/sbin:/bin:/usr/bin [PWD] => / [LANG] => C [SHLVL] => 2 [_] => /usr/sbin/httpd )
have also looked in $_SERVER & $GLOBALS.
Interestingly if I execute php -i in shell I see the env variables set correctly in _ENV
I should note im running this in a docker container, however I dont believe it is a issue as variables display correctly in #env & #php -i. I think I have a issue with my httpd/php config
Anyone have advice for this?
thanks

I ended up having a few options
if docker container needs to run multiple services, setting env vars to /etc/environment will make them available for all users. I added the following line to my Dockerfile CMD
CMD ["env | grep _ >> /etc/environment"]
if docker container runs a single service, its best to set the entry point to the desired application, env vars will automatically be passed to application user. this is my Dockerfile CDM & ENTRYPOINT to run apache
ENTRYPOINT ["/usr/sbin/httpd"]
CMD ["-D", "FOREGROUND"]

Dagon is correct.
Unless you logged in as your web server User (apache?) you may not see the same environment variables. You can see them easily with a phpinfo test file though:
<?php
phpinfo();
?>
Or you can set your own with a .htaccess file:
SetEnv HTTP_MY_VARIABLE "my value";
From dwitz: You can also make the environment variables available system wide with this:
env | grep _ >> /etc/environment
Sorry can't comment yet... So had to create an answer.

Recently i wrote a library to get values from environment variables and parse to the PHP data types. This library can be used to parse environment variables to PHP data types (like the casting to integer, float, null, boolean), parse the complex data structures like a JSON string and more with the contribution of the commnunity.
The library is available here: https://github.com/jpcercal/environment
As you say, the environment are already loaded. Then, to get the values from environment variable (independently of the environment CLI, Apache, Nginx, PHP Built-in Server and more) to do it:
<?php
// ...
require "vendor/autoload.php";
// ...
var_dump(Cekurte\Environment\Environment::get("YOUR_ENV_VARIABLE_NAME"));
Enjoy it.

Related

PHP SNMP Warning: SNMP::get(): No response from 127.0.0.1

I'm trying to get PHP SNMP to work on XAMPP PHP 7.1.9
I'm always getting this result: Warning: SNMP::get(): No response from 127.0.0.1
Here's what I did:
Enabled php_snmp.dll on php.ini
Installed net-snmp-5.5.0-2.x64
Added windows environment variable MIBDIRS with value C:\usr\share\snmp\mibs
Code I'm running to test:
<?php
$session = new SNMP(SNMP::VERSION_1, "127.0.0.1", "public");
$sysdescr = $session->get("sysDescr.0");
echo "$sysdescr\n";
$session->close();
I'm new to this so I'm not sure what I'm missing.
The problem was with the MIBDIRS path.
I followed php docs and it says:
The Windows distribution of Net-SNMP contains support files for SNMP in the mibs directory. This directory should added to Windows' environment variables, as MIBDIRS, with the value being the full path to the mibs directory: e.g. c:\usr\mibs.
Problem was I couldn't find c:\usr\mibs on my net-snmp installation so I used C:\usr\share\snmp\mibs instead.
Solution:
I tried using a device with snmp support instead of 127.0.0.1 and ran snmpget on cli and confirmed net-snmp installation actually works. I figured the problem must be with the path php is using to run snmp.
So I used where snmpget to check the command path then changed MIBDIRS environment value with the result which is C:\usr\bin\snmpget.exe

How does one enable the OCI8 PHP extension, using the Oracle Instant Client, in Ubuntu 18.04 LTS with PHP-FPM and NGINX?

I'm using the latest PHP packages available from https://launchpad.net/~ondrej/+archive/ubuntu/php .
When I build and install the OCI8 extension, everything appears to be in order, but despite enabling the extension in the PHP-FPM configuration, its presence is not reflected in the output from phpinfo().
The following Gist details the exact process that I'm using to configure, build, and install the OCI8 PHP extension:
https://gist.github.com/cbj4074/fa761f60b6f8db431539d76ebfba828e
The very same process and configuration work perfectly well on Ubuntu 16.04 LTS, so it seems that there is some fundamental difference on Ubuntu 18.04 LTS, whether with the operating system or the PHP packages in question.
As a bit of important (and I suspect relevant to this issue) background information, on Ubuntu 18.04 LTS, the extension fails to load in the CLI environment out-of-the-box, with the error:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20160303/oci8.so' - libmql1.so: cannot open shared object file: No such file or directory in Unknown on line 0
I resolved the issue like so:
# echo 'LD_LIBRARY_PATH="/opt/oracle/instantclient_12_2"' >> /etc/environment
I thought that perhaps adding the LD_LIBRARY_PATH to the PHP-FPM environment configuration might resolve the equivalent issue there:
# echo "env['LD_LIBRARY_PATH'] = /opt/oracle/instantclient_12_2" >> /etc/php/7.2/fpm/pool.d/www.conf
# systemctl restart php7.2-fpm
This does indeed cause the LD_LIBRARY_PATH value, as specified, to be reflected in both the Environment section of phpinfo() (when rendered via PHP-FPM + NGINX and requested from a browser) and the PHP Variables section, as $_SERVER['LD_LIBRARY_PATH'].
Oddly, even with PHP-FPM's logging set to debug, I don't see any trace of the libmql1.so error that I experience with the CLI. The OCI8 extension simply fails to load, silently. display_startup_errors = On in PHP-FPM's effective php.ini, too.
I elected to see if the OCI8 extension works in Apache, on the same server, and it does, provided I add export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 to /etc/apache2/envvars; in its absense, Apache complains on startup:
PHP Warning: PHP Startup: Unable to load dynamic library 'oci8.so' (tried: /usr/lib/php/20170718/oci8.so (libmql1.so: cannot open shared object file: No such file or directory), /usr/lib/php/20170718/oci8.so.so (/usr/lib/php/20170718/oci8.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
None of this business with the LD_LIBRARY_PATH is necessary on Ubuntu 16.04 LTS, and based on my observations herein and the comments regarding https://stackoverflow.com/a/45242468/1772379 , that changed in Ubuntu 17.10 and Ubuntu 18.04 LTS.
Has anybody else tried this, on Ubuntu 18.04 LTS, specifically?
I've tried this on two different Vagrant VMs, laravel/homestead box 6.0.0, and ubuntu/bionic64 box v20180509.0.0, and the behavior is the same in both.
Any other ideas would be most appreciated!
EDIT 1:
I asked about this issue on the package maintainer's GitHub tracker and he suggested that the problem stems from failing to set an appropriate RPATH at compile time.
I explain in my reply that I am setting an appropriate value, but the issue remains closed.
I do notice an interesting detail, however, which is that the compiled extension on Ubuntu 18.04 uses RUNPATH (and not RPATH, which is used in Ubuntu 16.04). If PHP-FPM ignores RUNPATH, and looks only for RPATH, it would explain this behavior.
EDIT 2:
This still-open report looks like an excellent candidate for having introduced the observed behavior:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732
(discovered through comments on use RPATH but not RUNPATH? )
EDIT 3:
On a commenter's advice, I reexamined updating the ld configuration before building the extension and that resolved the issue! I had tried this before, but must have overlooked something between build attempts:
# echo /opt/oracle/instantclient_12_2 > /etc/ld.so.conf.d/oracle-instantclient.conf
# ldconfig
I still don't know why LD_LIBRARY_PATH doesn't work as it should in this instance, but adding the Instant Client library path to the linker configuration seems a better approach besides.
EDIT 4:
I stated in my previous edit that modifying the ldconfig constitutes a better approach, but came to realize (on a commenter's good advice) that doing so can cause undesirable library conflicts, because the effects are system-wide.
In hindsight, it makes sense to minimize the "collateral damage" from runtime library linkage modifications by limiting them to the execution environment via the LD_LIBRARY_PATH. Accordingly, I am motivated to determine why this does not work on Ubuntu 18.04 LTS.
I feel that I have established definitively that the PHP-FPM daemon ignores LD_LIBRARY_PATH on Ubuntu (and has since at least Ubuntu 16.04 LTS; see Comments for explanation).
The ld.so(8) manpage states (in relation to the order in which runtime library paths are searched):
Using the environment variable LD_LIBRARY_PATH (unless the executable is being run in secure-execution mode; see below). [sic] in which case it is ignored.
As yet, I cannot think of any other reason for which the path would be ignored. Of secure-execution mode, the same document says:
Secure-execution mode
For security reasons, the effects of some environment variables are voided or modified if the dynamic linker determines that the binary
should be run in secure-execution mode. (For details, see the discussion of individual environment variables below.) A binary is exe‐
cuted in secure-execution mode if the AT_SECURE entry in the auxiliary vector (see getauxval(3)) has a nonzero value. This entry may
have a nonzero value for various reasons, including:
* The process's real and effective user IDs differ, or the real and effective group IDs differ. This typically occurs as a result of
executing a set-user-ID or set-group-ID program.
* A process with a non-root user ID executed a binary that conferred capabilities to the process.
* A nonzero value may have been set by a Linux Security Module.
Firstly, Secure-Execution Mode seems not to be in effect, as the PHP executables don't exhibit this flag (AT_SECURE is 0):
LD_SHOW_AUXV=1 /usr/sbin/php-fpm7.1 -daemonize --fpm-config /etc/php/7.1/fpm/php-fpm.conf
AT_SYSINFO_EHDR: 0x7ffc569e1000
AT_HWCAP: 178bfbff
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x55ceab0c4040
AT_PHENT: 56
AT_PHNUM: 9
AT_BASE: 0x7f823c77f000
AT_FLAGS: 0x0
AT_ENTRY: 0x55ceab19e360
AT_UID: 0
AT_EUID: 0
AT_GID: 0
AT_EGID: 0
AT_SECURE: 0
AT_RANDOM: 0x7ffc56962349
AT_HWCAP2: 0x0
AT_EXECFN: /usr/sbin/php-fpm7.1
AT_PLATFORM: x86_64
It occurred to me that the child FPM pool processes might exhibit different AT_SECURE values, but the output is identical for the PHP-FPM daemon itself, as well as any child processes. The parent and the children all have the following values:
# od -t d8 /proc/851/auxv
0000000 33 140722944548864
0000020 16 395049983
0000040 6 4096
0000060 17 100
0000100 3 93903778242624
0000120 4 56
0000140 5 9
0000160 7 140365152313344
0000200 8 0
0000220 9 93903779136352
0000240 11 0
0000260 12 0
0000300 13 0
0000320 14 0
0000340 23 0
0000360 25 140722944193929
0000400 26 0
0000420 31 140722944196579
0000440 15 140722944193945
0000460 0 0
Secondly, none of these reasons seem to apply, given the following:
1) There is no indication that PHP-FPM or its child processes have real and effective user or group IDs that differ (thanks to https://unix.stackexchange.com/a/202359 for this command):
# ps -e -o user= -o ruser= | awk '$1 != $2'
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
# ps -e -o group= -o rgroup= | awk '$1 != $2'
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
2) The binaries in question do not have any capabilities (the following commands produce no output):
# getcap /usr/lib/php/20170718/oci8.so
# getcap -r /opt/oracle/instantclient_12_2/
3) I have ensured that AppArmor is disabled (it doesn't have a policy that should affect PHP-FPM, anyway):
# systemctl disable apparmor
Synchronizing state of apparmor.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable apparmor
# reboot
# aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
So, why does PHP-FPM ignore LD_LIBRARY_PATH, if not for any of the aforementioned reasons?
EDIT 5 (Solution):
An astute commenter, #vinc17 , points-out that on systems running systemd, environment variables, such as LD_LIBRARY_PATH, are not necessarily propagated to processes that are started via a systemd Unit.
In other words, PHP-FPM isn't "ignoring" LD_LIBRARY_PATH, but rather, it is not being conveyed to the process. And attempts to set LD_LIBRARY_PATH within the PHP-FPM configuration are futile, because it's too late to do anything useful with the value.
On this advice, it occurred to me to set LD_LIBRARY_PATH in the systemd context, namely, in the Unit file(s) that start the PHP-FPM daemon(s), in which case PHP-FPM loads the OCI8 extension successfully.
Needless to say, we want to avoid editing the package maintainer's file (to avoid conflicts during future upgrades), so we extend it instead:
# mkdir /etc/systemd/system/php7.1-fpm.service.d
# touch /etc/systemd/system/php7.1-fpm.service.d/environment.conf
To this file we add the following:
[Service]
Environment=LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2
And to make the change effective:
# systemctl daemon-reload
# systemctl restart php7.1-fpm
For a more complete example, which addresses multiple co-installed PHP versions, please see my post at https://github.com/oerdnj/deb.sury.org/issues/865#issuecomment-395441936 .
First, Debian bug 859732 is a completely different issue (I would even say an opposite issue): for this bug, several versions of the library are present in the search path (one in some directory specified by LD_LIBRARY_PATH and a different one in some directory specified by the run path), but the wrong one is chosen by the dynamic linker.
In your case, the problem is that the requested library is not found anywhere in the search path. Note also that in your case, it is PHP that seems to try to open the library (via dlopen?), since the message starts with "PHP Warning:". However, it seems that the mechanisms are the same as with usual dynamic linking.
After installing the library, what you need is at least one of:
Nothing special if the library has been installed in a directory that is searched by default. Since you get an error, this is not your case.
Providing the directory in a run path, which must be specified at compile time of the software that will need the library. The problem is that under Linux, this is not done in standard by the build tools, and it may be complex to do it right without breaking other things. However, in the context of dlopen, the software (here, PHP) may have set up what one can call a "plugin search path", where you can put your libraries.
Providing the directory in LD_LIBRARY_PATH. This is what you tried, but your LD_LIBRARY_PATH seems incorrect. Libraries are usually installed in subdirectories named lib (or lib32 or lib64 in specific cases). So, export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 seems wrong. Search for the full pathname of the library oci8.so, and just take the directory part of this pathname for LD_LIBRARY_PATH.
Note: strace may be useful to see what directories are considered to search for the libraries. EDIT: ldd and objdump -p are other useful tools to find what's going on with the search paths.
EDIT 2: Another point to note when choosing to use a run path is that indirect library dependencies are found when RPATH is used, but not when RUNPATH is used (so, in this latter case, all dependencies also need to have a run path if they depend on other libraries so that all libraries can be found without resorting to LD_LIBRARY_PATH). This is documented in recent versions of the ld.so(8) man page:
Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present. Such directories are searched only to find those objects required by DT_NEEDED (direct dependencies) entries and do not apply to those objects' children, which must themselves have their own DT_RUNPATH entries. This is unlike DT_RPATH, which is applied to searches for all children in the dependency tree.
This is probably why, without using LD_LIBRARY_PATH, this was working with 16.04 (where RPATH is used) but not with 18.04 (where RUNPATH is used).

Environment variable not recognised when deploying to Elastic Beanstalk

I'm trying to deploy my Laravel application to Elastic Beanstalk in development mode. To make the application run in development mode rather than production, I've done the following in my /bootstrap/start.php file:
$env = $app->detectEnvironment(function() {
return $_ENV['ENV_NAME'];
});
To actually create the environment variable, I've created a .config file in the following path: /.ebextensions/00environmentVariables.config with these contents:
option_settings:
- namespace: aws:elasticbeanstalk:application:environment
option_name: ENV_NAME
value: development
- option_name: DB_HOST
value: [redacted]
- option_name: DB_PORT
value: [redacted]
- option_name: DB_NAME
value: [redacted]
- option_name: DB_USER
value: [redacted]
- option_name: DB_PASS
value: [redacted]
When I run eb start from the command line, it spins up an EC2 instance and attempts to provision it, at which point it tells me it fails. and to check the logs. In the logs, I can see these entries:
PHP Notice: Undefined index: ENV_NAME in
/var/app/ondeck/bootstrap/start.php on line 28
Notice: Undefined index: ENV_NAME in /var/app/ondeck/bootstrap/start.php on line 28
So for some reason, the ENV_NAME environment variable doesn't exist, even though I've specified it in 00environmentVariables.config. What's even weirder, is that I can see the environment variable does exist under the software configuration settings of the EB environment:
To summarize:
I know my .config files are being parsed from looking at the logs
For some reason my Laravel application still doesn't think that ENV_NAME eixsts
ENV_NAME eixsts both in the .config file and in my Elastic Beanstalk settings for this environment
EDIT
Alright so I worked out that the environment variables do work correctly when serving the application over the Apache HTTP server, but the environment variables don't exist when running the PHP CLI.
In the above logs, it's complaining about ENV_NAME not existing when running a /usr/bin/composer.phar install.
So, for some reason, my environment variables don't exist within the PHP CLI but they do work normally when serving over Apache.
FURTHER EDIT
So I SSH'd into the EC2 instance that's hosting my Laravel application on Elastic Beanstalk, and I can see the proper environment variables when I use the ``printenv command`:
ENV_NAME=development
However, if I do a die(var_dump($_SERVER)); and run the PHP CLI, I don't see the environment variables that I've defined. Same story with $_ENV and getenv().
Why can't I access my environment variables within the PHP CLI, when I can access them when Apache processes my PHP scripts?
YET ANOTHER EDIT
I made a test.php file with one line: die(var_dump($_ENV));.
When I run this using php test.php I successfully get my custom environment variables coming out, so this seems like a composer only problem, not a PHP CLI problem.
I use a YAML script which sets the environment variables for the root user from the existing variables set for ec2-user. Add this to your .ebextensions folder with the .config extension.
From there you can run PHP cli and it will see the correct environment variables
commands:
create_post_dir:
command: "mkdir /opt/elasticbeanstalk/hooks/appdeploy/post"
ignoreErrors: true
files:
"/opt/elasticbeanstalk/hooks/appdeploy/post/job_after_deploy.sh":
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
source /opt/elasticbeanstalk/support/envvars
# Run PHP scripts here. #
From XuDing's answer to this question and this answer
I created a job that creates .env file every 5 minutes.
Add the following to your .ebextensions
"/opt/elasticbeanstalk/hooks/appdeploy/post/91_set_create_app_env_file_job.sh":
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
echo "Removing any existing CRON jobs..."
crontab -r
APP_ENV=/var/app/current/.env
EB_ENVVARS=/opt/elasticbeanstalk/support/envvars
CONSTANTS=/var/app/current/.constants
CRON_CMD="grep -oE '[^ ]+$' $EB_ENVVARS > $APP_ENV; cat $CONSTANTS >> $APP_ENV"
echo "Creating .env file...."
eval $CRON_CMD
echo "Scheduling .env file updater job to run every 5 minutes..."
(crontab -l 2>/dev/null; echo "*/5 * * * * $CRON_CMD")| crontab -
Reason I did it this way is that you may want to update your environment variables via the AWS UI Console.
This is the best solution in my opinion.

No environment variables are available via PHP-fpm+nginx

I tried to modify php.ini in the following way:
variables_order = "GPCSE"
register_globals = On
But the required PATH variable is neither in $_ENV nor accessible via getenv('PATH').
I'm running Nginx + PHP-FPM on Ubuntu 10.04.
Note:
executing the following command in console gives a correct result:
php -r "echo getenv('PATH');"
I guess that PATH is environment variable of bash, but as long as php-fpm not starting via bash it doesn't have required variables. Any way to include them?
Thanks.
Update#1:
As temporary solution I found out that PATH variable stored in '/etc/environment' file. So I just going to read it from there. If someone needs a code:
preg_match('/^(PATH)="?([^"]+)"?$/i', file_get_contents('/etc/environment'), $match);
putenv($match[1]."=".$match[2]);
By default, PHP-FPM clears the environment variables (from the www.conf):
; Clear environment in FPM workers
; Prevents arbitrary environment variables from reaching FPM worker processes
; by clearing the environment in workers before env vars specified in this
; pool configuration are added.
; Setting to "no" will make all environment variables available to PHP code
; via getenv(), $_ENV and $_SERVER.
; Default Value: yes
;clear_env = no
You can uncomment the last line to set clear_env to no, but if you prefer, you can set only the environment variables needed:
env[PATH] = $PATH
I came across this problem when upgrading my OwnCloud installation to version 8.1.
They describe a fix in their documentation
Summary is: Locate your www.conf file in your php5-fpm config folder (for Ubuntu this is /etc/php5/fpm/pool.d/www.conf) and uncomment the needed env[PATH] line.
Optionally update the content of the variable with the output of php -r "echo getenv('PATH');"
You could specify it via an include path: http://www.php.net/manual/en/ini.core.php#ini.include-path
You can specify it your php.ini (though you may want a specific path instead of including everything)
include_path=".:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/fo‌​ta/Development/adt-bundle-linux-x86_64-20130917/sdk/platform-tools "

$PATH environment variable for apache2 on mac

I am trying to get apache/php to recognize the path to my git. I have been researching and looking in all corners of the web and cannot find how to do this. Basically, no matter what I try, when I run echo phpinfo(); the Apache Environment path does not change from /usr/bin:/bin:/usr/sbin:/sbin. And when I run system('echo $PATH'); in PHP, it reads the same.
System Information:
Mac OSX (Lion)
Apache 2 (running as _www)
PHP 5.3.6
Here is what I have tried editing so far:
/etc/profile
~/.bash_profile
~/.profile
/etc/path
/etc/path.d/{NEW_FILE}
Nothing I have tried so far has changed the $PATH variable. Any ideas?
SOLUTION
So here is the final solution. I edited the
/System/Library/LaunchDaemons/org.apache.httpd.plist
and added
<key>EnvironmentVariables</key>
<dict>
<key>PATH</key>
<string>/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin</string>
</dict>
You can set the PATH environment variable in /System/Library/LaunchDaemons/org.apache.httpd.plist.
More in the docs.
Did you update the PATH environment variable of user '_www'? Apache will read environment variables from the user runs itself. Or, it looks like you didn't restart apache after updating PATH environment variable.
Check out the older discussion :
How do I add paths to the Apache PATH variable?
Setting environment variables in OS X?
And if you want to modify environment variable in PHP, getenv() and putenv() can be a better choice.
getenv : http://php.net/manual/en/function.getenv.php
putenv : http://www.php.net/manual/en/function.putenv.php
$path = getenv('PATH');
putenv( "PATH=$path:/new_path_that_you_want_to_add" );
Important note for El Capitan (Apologies for the new answer - I don't have enough Rep to comment)
On OSX 10.11, the /System/Library folder is protected, so the files can't be edited.
You need to:
Reboot into Recovery Mode (hold CMD + r after the startup sound)
Once in recovery mode, go to Utilities > Terminal
Run:
csrutil disable
Reboot back into OSX - you should now be able to change the files
Once done, go back to recovery mode and run
csrutil enable
Hope that helps
I created this gist that helped me out from the information above:
https://gist.github.com/srayhunter/5208619
My problem was that PHP was not finding a program that we had installed under /usr/local/bin. Once we did the above it all worked and played nice on mac osx.
for ubuntu server, in /etc/apache2/envvars,
for centos server, in /etc/sysconfig/httpd,
to add:
export PATH=<your php cli path>
and restart apache
A similar problem to what I was having installing Derby. The way I solved it was by opening TextEdit. Select File > Open at this point press Shift + Command + . , this will allow you to view all the documents. Head to the user directory and search for a file called ".profile" . Open it and add the export VARIABLE= Value line for example:
export DERBY_HOME=/opt/local/share/java/derby/
Save the document and restart your terminal to see if the changes went into affect.

Categories