This is on CentOS 7.2, PHP version 5.6.20. According to readline_info():
<?php
print_r(readline_info());
gives
Array
(
[line_buffer] =>
[point] => 0
[end] => 0
[library_version] => EditLine wrapper
[readline_name] =>
[attempted_completion_over] => 0
)
OK, so readline() is using EditLine. I created a ~/.editrc file with:
bind -v
The permission is 664. I then tried:
<?php
$line = readline('Enter: ');
But it doesn't seem to read the file, and it's not in Vim mode. Doing an Alt-X followed by a manual command of "bind -v" puts it in Vim mode, so I know it has Vim mode.
I read somewhere else that I might need to manually set the path in an environment variable. So tried setting the full path:
$ export EDITRC=/home/work/.editrc
Still nothing. I've also seen that "export EL_EDITOR=vi" is supposed to work, but still doesn't work.
Does anyone have any way to make this work? I really need Vim mode to work.
Related
I'm having trouble running a python script using shell_exec or exec using PHP 7 (PHP Version 7.0.33-0+deb9u3).
If I run: var_dump(shell_exec("/usr/bin/python3 /home/pi/Documents/GTranslate/translator.py")); or var_dump(shell_exec("/home/pi/Documents/GTranslate/translator.py"));,
I obtain back NULL.
No problems with user permissions
I've checked the permission running:
$scriptPath = "/home/pi/Documents/GTranslate/translator.py";
var_dump(array(
'file' => is_file($scriptPath),
'readable' => is_readable($scriptPath),
'executable' => is_executable($scriptPath)
));
I've obtained everything true.
Missing safe_mode from php.ini
In my php.ini (the one shown by phpinfo();) there is no fields like safe_mode. Reading the PHP Wiki since PHP 5.4.0 the function has been removed.
shell_exec() is working
The funcion shell_exec() is not disabled because if I run the command:
echo shell_exec("ls -halt /home/pi/Documents/GTranslate/translator.py");
I obtain back:
-r-xr-x--x 1 pi pi 1.7K Aug 11 12:13 /home/pi/Documents/GTranslate/translator.py
Where is the problem?
After 3 hours of searches and differents failed tries, I'm asking help here .. .:(
My configuration:
PHP 5.4.12
Compiler MSVC9
OS: W7 Home premium edition service pack 1
Architecture: x64
Apache: 2.4.4
I've tried many php_apc.dll without success. Is someone found the right one to use or any good alternative to APC?
PHP APC extension for PHP 5.3x to PHP 5.4 and PHP APCu extension for PHP 5.5x
APC installation:
Step 1:
Download APC dll file for PHP 5.3x to 5.4
Step 2:
Extract zip and rename with php_apc.dll
Step 3:
Copy and paste in YOUR_DIR:\wamp\bin\php\php_YOUR_PHP_VER_5.3x_OR_5.4\ext
Step 4:
Enable apc from php.ini
Open php.ini file
YOUR_DIR:\wamp\bin\apache\apache_YOUR_APACHE_VER\bin\php.ini
extension=php_apc.dll
Put above line in php.ini file
OR (Base on your configuration)
YOUR_DIR:\wamp\bin\php\php_YOUR_PHP_VER_5.3x_OR_5.4\php.ini
extension=php_apc.dll
Put above line in php.ini file
Step 5:
Restart Apache
APCu installation for PHP 5.5x:
Step 1:
Download APCu dll file for PHP 5.5x
Step 2:
Extract zip and rename with php_apcu.dll
Step 3:
Copy and paste in YOUR_DIR:\wamp\bin\php\php_YOUR_PHP_VER_5.5x\ext
Step 4:
Enable apc from php.ini
Open php.ini file
YOUR_DIR:\wamp\bin\apache\apache_YOUR_APACHE_VER\bin\php.ini
extension=php_apcu.dll
Put above line in php.ini file
OR (Base on your configuration)
YOUR_DIR:\wamp\bin\php\php_YOUR_PHP_VER_5.5x\php.ini
extension=php_apcu.dll
Put above line in php.ini file
Step 5:
Restart Apache
Installing APC seems fairly simple. I just did it in 10 minutes.
This assumes you are using a 32bit WAMP even on a 64bit Windows. It seems rather hard to find a precompiled 64bit version of APC so if you are using the 64bit WAMP maybe installing the 32bit WAMP would be a good idea.
My Environment is WAMPServer 2.4
The version of PHP I tested this with was 5.3.22 which was running under Apache 2.2.26
I got the dll's from HERE
and selected php_apc-3.1.10-5.3-vc9-x86.zip for my PHP5.3 Versions
and selected php_apc-3.1.10-5.4-vc9-x86.zip for my PHP5.4 Versions
These are compiled with VC9 (msvc 2008) and match the compiler used to create PHP and APACHE
Extract the zips somewhere and then copy the php_apc.dll from the ts (thread safe) folder into your php/ext folder
Edit your php.ini ( using the wampmanager menu links so you get the correct file ) and add this line to the existing section of extension parameters.
extension=php_apc.dll
While in the php.ini add these parameters for apc at the bottom of the ini file
[apc]
; default memory allocation = 32M
apc.shm_size = "32M"
; for dev check for changed code every time so set to "1". "0" for LIVE site.
apc.stat = "1"
This is not actually changing anything as these are actually the defaults, but its a useful place holder for when you decide you want to start fiddling with APC's parameters.
Now to test that the new extension has been loaded, restart apache again using the wampmanager menu, then launch localhost from the menu and click the phpinfo ilnk on the homepage. APC should be the first extension shown in the list of loaded extensions.
Now create a little script to verify apc is working and place it in the \wamp\www folder
filename = test_apc.php
<?php echo '<pre>' . print_r(apc_sma_info(),TRUE) . '</pre>'; ?>
Now run the script from your browser:
http://localhost/test_apc.php
You should see something like this reported:
Array
(
[num_seg] => 1
[seg_size] => 33554368
[avail_mem] => 7396512
[block_lists] => Array
(
[0] => Array
(
[0] => Array
(
[size] => 608
[offset] => 25985176
)
[1] => Array
(
[size] => 6696
[offset] => 26108536
)
[2] => Array
(
[size] => 11912
[offset] => 26116296
)
[3] => Array
(
[size] => 552
[offset] => 26011544
)
)
)
)
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.
I made a custom PHP module with C++ and Swig. It works from the command line, but not with my webserver:
php index.php
php-cgi index.php
Both of those work fine.
I'm using lighttpd and php. I didn't configure these in any special way. I just installed them using sudo apt-get install.
Unfortunately if I make a webpage I get this:
Fatal error: Call to undefined function minikey_to_wif() in /var/www/index.php on line 6
Calling function_exists("minikey_to_wif") returns False too.
The phpinfo() does not show my module called minikey, and shows the same configuration path as the file I edited (/etc/php5/cgi/php.ini):
extension=/path/to/php-ext/minikey/minikey.so
I also tried copying it to where the other PHP extensions seem to be installed (/usr/lib/php5/20090626+lfs/) but that didn't work either.
I've been stopping, and starting lighttpd countless times. Each time, when I run ps aux | grep php, there are no results. I've also rebooted a few times to no effect. I have no idea what's up.
OK found the answer.
The extension relied on a library which was installed in a non-standard location. Normally I set LD_LIBRARY_PATH in ~/.bashrc. But when the web server ran the extension, it didn't have that environment variable.
Fix was to create a file in /etc/ld.so.conf.d/genjix.conf with /home/genjix/usr/lib and run ldconfig as root.
Try running phpinfo() using lighty. Make sure that its pointing to the correct php.ini.
If you think this is the problem you can launch php using the -c switch from inside lighttpd.conf with "bin-path" => "/path/to/php-cgi -c /path/to/php.ini":
e.g.
fastcgi.server = (
".php" => (
(
"bin-path" => "/path/to/php-cgi -c /path/to/php.ini",
"socket" => "/tmp/php.socket",
"max-procs" => 4,
"idle-timeout" => 30,
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "4",
"PHP_FCGI_MAX_REQUESTS" => "1000"
)
)
)
)
The code I'm working on runs perfectly on Windows XP and on Mac OS X. When testing it on CentOS (and on Fedora and Ubuntu), it's not working properly. Searching the nets led me to the conclusion that it's the glibc version of the iconv that's causing the problem. So now I need the libiconv version of iconv for Zend Lucene to work properly.
I already downloaded libiconv and configured it with --prefix=/usr/local, make, then make install without any errors. It seems that it was successfully installed because executing /usr/local/bin/iconv --version says the version is the libiconv. Although a simple iconv --version still gives the glibc version.
Then I recompiled PHP from source using --with-iconv=/usr/local. But still, the phpinfo() is showing the iconv being used is the glibc version. I've also already tried several other compiles using --with-iconv-dir or using /usr/local/bin/php.
Of course, I restarted the web server after recompiling PHP.
I have the following line in my /etc/httpd/conf/httpd.conf:
LoadModule /usr/lib/httpd/modules/libphp5.so
and libphp5.so is actually in /usr/lib/httpd/modules.
phpinfo() shows PHP 5.3.3. I also yum removed the pre-installed PHP 5.1.* just to make sure. But the iconv is still using the glibc version.
ldd /usr/lib/httpd/modules/libphp5.so gives
linux-gate.so.1 => (0x003b1000)
/usr/local/lib/preloadable_libiconv.so (0x00110000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x001ed000)
librt.so.1 => /lib/librt.so.1 (0x0021f000)
libmysqlclient.so.15 => /usr/lib/mysql/libmysqlclient.so.15 (0x003b2000)
libldap-2.3.so.0 => /usr/lib/libldap-2.3.so.0 (0x0026e000)
liblber-2.3.so.0 => /usr/lib/liblber-2.3.so.0 (0x00370000)
libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x00516000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x002a8000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00228000)
libz.so.1 => /usr/lib/libz.so.1 (0x00328000)
libcurl.so.3 => /usr/lib/libcurl.so.3 (0x00f23000)
libm.so.6 => /lib/libm.so.6 (0x0033b000)
libdl.so.2 => /lib/libdl.so.2 (0x00364000)
libnsl.so.1 => /lib/libnsl.so.1 (0x0037e000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00f5f000)
libssl.so.6 => /lib/libssl.so.6 (0x0862c000)
libcrypto.so.6 => /lib/libcrypto.so.6 (0x04145000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x08e2d000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x0611a000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x005f4000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x0024e000)
libidn.so.11 => /usr/lib/libidn.so.11 (0x071f5000)
libc.so.6 => /lib/libc.so.6 (0x08aa6000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00397000)
/lib/ld-linux.so.2 (0x00251000)
libresolv.so.2 => /lib/libresolv.so.2 (0x0748a000)
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x07ddf000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x062b7000)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00369000)
libselinux.so.1 => /lib/libselinux.so.1 (0x0913b000)
libsepol.so.1 => /lib/libsepol.so.1 (0x07eb4000)
This is a cross-post from: NullPointer.ph
I just have changed my php-5.3.3 from glibc's iconv to GNU libiconv through the manual recompiling of the php iconv extension. Follow these steps:
download php-5.3.3 source code package
extract it and go into php-5.3.3/ext/iconv subdirectory
execute phpize command (if you have no such command then install php-devel package)
(*) edit configure file (vim configure): add iconv_impl_name="" at 4664 line (exact line number on your system configuration may be different):
...
iconv_impl_name=""
if test -z "$iconv_impl_name"; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if using GNU libiconv" >&5<
...
./configure --with-iconv=/usr/local|grep iconv:
checking if using GNU libiconv... yes
make
sudo make install
And now I run php -i|grep "iconv impl" and got:
iconv implementation => libiconv
* This trick forces configure to select the GNU libiconv instead of glibc's iconv. By default it checks for glibc's iconv at first step and does not check for GNU libiconv at all.
Your module (libphp5.so) is linked to two shared libraries which are providing the same symbol (in this case the symbol is iconv and the libraries are libiconv.so.2 and probably libc.so.6).
When this happen, the first loaded symbol is used: probably libc.so.6 gets loaded before libiconv.so.2 and thus it's the one providing you with the iconv symbol.
You can force the dynamic loader to load a library before any other; you can do this by setting the LD_PRELOAD environment variable to the library you want to preload.
I'm not an expert about Apache, so I'm not totally sure about how it works, how it starts its process and what processes it uses, but I think that setting LD_PRELOAD before running apache should do the trick:
LD_PRELOAD=/usr/local/lib/libiconv.so.2
A little example to show LD_PRELOAD in action:
Will compile myfopen.c as a shared library (myfopen.so): it will provide a fopen symbol (already defined in libc):
$ cat myfopen.c
int fopen(const char *path, const char *mode){ return -1; }
$ gcc -o libmyfopen.so myfopen.c -shared
Compiling printfopen.c as an executable (printfopen) which just prints the result of fopen; will link it against both libc and libmyfopen (LD_LIBRARY_PATH is needed to let the linker look for the libraries also in .):
$ cat printfopen.c
#include <stdio.h>
int main( ) {
printf( "%d\n", fopen("","") );
return 0;
}
$ gcc -o printfopen printfopen.c -L. -lmyfopen
$ LD_LIBRARY_PATH=. ldd printfopen
linux-gate.so.1 => (0xb779d000)
libmyfopen.so => ./libmyfopen.so (0xb779a000)
libc.so.6 => /lib/libc.so.6 (0xb762f000)
/lib/ld-linux.so.2 (0xb779e000)
Now I'm running it, to test if LD_PRELOAD works:
$ LD_LIBRARY_PATH=. ./printfopen
-1
$ LD_PRELOAD=/lib/libc.so.6 LD_LIBRARY_PATH=. ./printfopen
0
$ LD_PRELOAD=libmyfopen.so LD_LIBRARY_PATH=. ./printfopen
-1
By default it loads libmyfopen before libc, then I tried to force loading libc and then libmyfopen first.
I guess that in your case libc is getting loaded before libiconv because the former is loaded by the application (apache?) before it loads the PHP module.
Are you sure that LD_LIBRARY_PATH is set properly for httpd (web server) process?
If not, try setting it like:
export LD_LIBRARY_PATH="/usr/local/lib:${LD_LIBRARY_PATH}"
... in the script that starts the process (i.e. apachectl).
The ldd output you showed looks correct, but you invoked ldd from user's environment, and httpd's might be different.
It could also help to set PATH to "/usr/local/bin:${PATH}", just in case.
I understand, that this question is already answered and almost dead, but recently I tried to find a way to compile PHP with libiconv because in PHP I couldn't convert "∙" from UTF8 to CP1251 even with iconv //IGNORE.
But I found another solution that worked for me without recompilation (just use //TRANSLIT):
iconv("UTF8", "CP1251//TRANSLIT//IGNORE", $text)
//TRANSLIT will transliterate ONLY unknown characters (not all, as some may guess), so it converts Russian 'ё', but transliterates unknown '∙' to 0x95 (which looks the same in the target charset).
I do not know about CentOS, but in debian based distributions, like Ubuntu, you can choose the version of the program that you want to lauch defining the symbolic links at /etc/alternatives.
So, if you change the symbolink link /etc/alternatives/iconv in order to point to /usr/local/bin/iconv, this point forward it should use the correct version.
http://www.debian-administration.org/articles/91