I installed node.js from sources (./configure && make && make install) under /usr/local/bin/node. Afterwards I installed the less compiler globally with npm -g install less under /usr/local/lib/node_modules/less/. So node and less are located under their default paths.
I am using kriswallsmith/assetic to compile my less files through PHP, therefore I adjusted path to /usr/local/bin/node. Everytime I run my script I get the error Error: Cannot find module 'less', I had the same behavior through command line. But I found a solution (ln -s /usr/local/lib/node_modules/ ~/.node_libraries) to fix the problem and after this it worked out on command line. Through PHP the problem still persists - PHP is running through FastCGI with the same user I used on command line.
How can I fix this problem through FastCGI/PHP too?
Constructor of assetic's LessFilter accepts an array of nodePaths. Adding /usr/local/lib/node_modules/ as a nodePath solves the problem.
Related
I'm in a multi developer program. The other developer installed PHPUnit via composer and successfully is running tests. I took the composer files, ran composer update, but when I try to run the tests, I am receiving this error:
C:\Repos\Project\TDD>php vendor/bin/phpunit
Output:
dir=$(cd "${0%[/\\]*}" > /dev/null; cd "../phpunit/phpunit" && pwd)
if [ -d /proc/cygdrive ]; then
case $(which php) in
$(readlink -n /proc/cygdrive)/*)
# We are in Cygwin using Windows php, so the path must be translated
dir=$(cygpath -m "$dir");
;;
esac
fi
"${dir}/phpunit" "$#"
This is the content of the phpunit shell script. The shebang first line #!/usr/bin/env sh is not being output, but this is the rest of the file. The problem appears to be that the PHP CLI is not executing the script, just reading it. I can't figure out how to fix that.
I am on a windows environment, and I am not running apache locally.
Things I have tried:
I have tried using full paths (eg, C:/php/php.exe) for both the php and the shell script, and that didn't matter.
I have tried reversing the slashes vendor\bin\phpunit
I can run php -v successfully, but php -f vendor/bin/phpunit still just outputs the file contents.
I have confirmed the PATH for php is accurate and restarted.
All expected vendor files do appear to be present.
Composer update is not throwing errors of any kind.
I've changed my terminal / CLI processor to use powershell instead of the default cmd.exe (same result as above)
I've confirmed encoding of the phpunit file is UTF-8 without BOM
I've tried making the php command execute the phpunit script in powershell and git bash directly with no luck --- it outputs the shell file. It seems to be that php is just not executing it, which makes me think there is a problem with my php.ini or something.
I CAN run the phpunit shell directly, such as phpunit --version, but I can't get it to run my tests.
I set the composer platform to match my cli php -v
"config": {
"platform": {
"php": "7.4.20"
}
}
Edit: Interestingly, I uploaded it all to my LAMP webserver and ran the same script there, and it is not executing there either. It's outputting the files...
There is a lot of stuff you're fiddling with while trouble-shooting your issue, so there can be only giving extended comments on it. Take it with a grain of salt and pick the pieces that make sense to you, it looks to me you're clever and should be close to the point where you connect the dots more soon than later (don't give up):
C:\Repos\Project\TDD>php vendor/bin/phpunit
This on your windows shell prompt command the php binary to execute the (php) script vendor/bin/phpunit.
And PHP does exactly this (everything else would be a surprise, right?), it executes that script.
The output you see confirms it. As php is the PHP CLI SAPI (PHP Command Line Binary), the first line starting with # is not output (you can find this behaviour described in the PHP documentation as well: https://www.php.net/manual/en/features.commandline.usage.php and on antoher place that I can't find right now that exactly describes this difference to the common mode https://www.php.net/manual/en/language.basic-syntax.phpmode.php).
You then correctly analyze:
This is the content of the phpunit shell script.
and make the note on the shebang line:
#!/usr/bin/env sh
So this looks to me that this shell script vendor/bin/phpunit is not to be executed with the given commandline:
php vendor/bin/phpunit
but instead just by:
C:\Repos\Project\TDD>vendor/bin/phpunit
Which won't (or might not) work on your windows system.
Some more background information (this applies to phpunit bin-stubs as well as other when installed as composer(1) dependencies):
composer manages these scripts (for you)
composer handles them for POSIX compatible systems as well as for others (compare the /usr/bin/env sh which is stupid, it's /bin/sh, always, may need a report on the composer project) incl. windows or windows with cygwin or WSL running on Windows, Vagrant box setups etc. pp. (yes they really care since years).
composer handles this at the time of install/update.
for windows (which I can't compare are not using it but from what I remember) composer is adding .bat or .cmd files next to the commands (as that is how Windows handles executables).
So mabye using:
C:\Repos\Project\TDD>composer exec phpunit
already solves your invocation problem.
Or
C:\Repos\Project\TDD>vendor\bin\phpunit.bat
Or
C:\Repos\Project\TDD>vendor\bin\phpunit.cmd
Or
C:\Repos\Project\TDD>vendor\bin\phpunit
does. Point in case is this: https://getcomposer.org/doc/articles/vendor-binaries.md
All in all this looks to me you got instructions from one developer working on a unixoide sytem (Mac, Linux) and you're running on Windows. This should not pose a problem on that level, however the onboarding in your team might be low or it's just the knowledge management (unfortunately after a decade or more of Stackoverflow this got worse) and you've been left alone with the trouble shooting.
It's not a programming problem, but merely getting the tooling to run.
Perhaps there is some regime about composer and running it which prevents you from looking there first. But this is hard to say on Stackoverflow.
I'd start fresh with the project, remove it from disk and install it anew. This must work, always. To not sink the current project you can do this a-new in a second directory (the project might support composer create-project to give it a quick start - that is cloning new and doing the composer install).
Similar it is that you could do a composer update in the existing project (which is intended to modify it and depending on how well the project you work with is integrated with composer and your development platform will enable or break things).
At the end of the day the common workflow is:
> rmdir vendor
(remove the vendor directory, that is the blank slate)
> composer install
(install the vendor directory, that is all PHP dependencies of the project)
> composer exec phpunit
(execute the phpunit test-runner)
Edit: Interestingly, I uploaded it all to my LAMP webserver and ran the same script there, and it is not executing there either. It's outputting the files...
Never install phpunit on a webserver system. Run it in development or CI, but not on the webserver. Period. (this has security implications, and it won't help you to execute it there, you need to run it where you develop when you're doing TDD - keep this focus for troubleshooting)
The true path to the PHP script that is represented by vendor/bin/phpunit is:
vendor/sebastianbergmann/phpunit/phpunit
(you can find it in the composer.json of phpunit https://github.com/sebastianbergmann/phpunit/blob/master/composer.json#L66)
Given your original command-line and from the various other information you give, this should work:
php vendor/sebastianbergmann/phpunit/phpunit
I have a Virtuoso server running on Centos7 and have been trying to be able to execute PHP files from an HTML form (even really basic ones just to test), and have had no luck. I found out I had to install PHP and have been reading the documentation from the virtuoso GitHub README.php5 to setup PHP on the virtuoso server. This is my first time setting up PHP and I have run into an issue when trying to run the make command. I am in directory /etc/php-5.2.10 and have been able to run the configure command with all the flags. The error from the make command I receive is:
/bin/sh /etc/php-5.2.10/libtool --silent --preserve-dup-deps --mode=compile
/etc/php-5.2.10/meta_ccld -I/usr/local/iODBC/include -Iext/odbc/ -I/etc/php-5.2.10/ext/odbc/
-DPHP_ATOM_INC -I/etc/php-5.2.10/include -I/etc/php-5.2.10/main -I/etc/php-5.2.10
-I/usr/local/iODBC/include -I/etc/php-5.2.10/ext/date/lib -I/usr/include/libxml2
-I/etc/php-5.2.10/ext/mbstring/oniguruma -I/etc/php-5.2.10/ext/mbstring/libmbfl
-I/etc/php-5.2.10/ext/mbstring/libmbfl/mbfl -I/etc/php-5.2.10/TSRM -I/etc/php-5.2.10/Zend
-D_REENTRANT -I/usr/include -g -O2 -pthread -DZTS
-c /etc/php-5.2.10/ext/odbc/php_odbc.c -o ext/odbc/php_odbc.lo
In file included from /etc/php-5.2.10/ext/odbc/php_odbc.c:37:0:
/etc/php-5.2.10/ext/odbc/php_odbc_includes.h:104:22: fatal error: iodbcext.h:
No such file or directory
#include <iodbcext.h>
^
compilation terminated.
make: *** [ext/odbc/php_odbc.lo] Error 1
I do not know if these packages are related but for extra information, I have the following packages installed as well:
libiodbc.x86_64 3.52.7-7.el7
libiodbc-devel.x86_64 3.52.7-7.el7
php-odbc.x86_64 5.4.16-36.el7_1
unixODBC.x86_64 2.3.1-10.el7
unixODBC-devel.x86_64 2.3.1-10.el7
I have run sudo find / -iname '*iodbcext.h*' to try and determine where that file may be located and the only result I get back is /usr/include/libiodbc/iodbcext.h. However, I am not sure if that is what make is looking for or if there is supposed to be another one within the php-5.2.10 directory that is used, and if that is the right one, what would I do with it?
Any assistance or advice in getting PHP setup on the Virtuoso server is greatly appreciated.
You have conflicting packages installed, for the iODBC and unixODBC driver managers. It is strongly advised that you choose one or the other. Given that you're using Virtuoso (from my employer, OpenLink Software), I'd advise that you settle on iODBC (also maintained and supported by OpenLink Software, and generally expected to be found by Virtuoso).
PHP doesn't include the iODBC SDK (libiodbc-devel.x86_64), which is where the header file iodbcext.h would be found. I should note that the current version of iODBC is 3.52.10, somewhat later than the package you've installed...
It's not clear what options you passed to configure to get the make script you're running. You may be able to get past the error reported above by editing the second occurrence of -I/usr/local/iODBC/include in the make script, changing it to -I/usr/include/libiodbc ... but this is something of a guess.
I struggle to be able to run PHP client line interface on Cygwin. I receive constantly Segmentation fault error. But some of functions are correctly done - I cannot say when does it happen.
If somebody had this error, please give me any clue to correctly run PHP CLI under cygwin.
Thanks in advance!
EDIT
I Receive stackdump, but I don't know if it tells anything:
Exception: STATUS_ACCESS_VIOLATION at eip=603B7AC6
eax=0000000A ebx=FFE42FFF ecx=002853E0 edx=FFE43000 esi=00000000 edi=FFE43000
ebp=002853E2 esp=00285240 program=C:\cygwin\bin\php.exe, pid 10056, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
002853E2 603B7AC6 (022A018F, 02D40284, 0348030B, 0374034D)
00040002 00F30055 (00340000, 01E00000, 020C0000, 00360000)
Moreover I tried to limit in php.ini
pcre.recursion_limit=1000
no effect.
It crashes every time when I work with client line interface. If I run it through Apache2 there is no problem.
How can I debug it effectively?
EDIT
I run it with php-cgi, where I receive the html output with error description:
ContextErrorException: Warning: Invalid argument supplied for foreach() in ...
Having this information I guess that there is a problem with input arguments. If I run scripts without arguments from console I don't receive segmentation fault.
This is Symfony framework and those scripts run like a charm on windows and ubuntu on console. So I guess:
- there is something wrong with PHP settings
- there is something wrong with console on Cygwin
Any idea how can I debug it more?
After long hours of useless research I end up with removing php5 and php from Cygwin and mapping there standalone PHP for Windows.
For anyone facing this problem:
Uninstall all "PHP" group of extensions for cygwin
Run cygwin
rm -f /usr/bin/php.exe
rm -rf /usr/share/php
Download and install brand new PHP for Windows
ln -s /cygdrive/c/your/path/to/php/php.exe /usr/bin/php.exe
So I don't know why this issue occured to me, but fresh native php for windows installation helped.
I am installing wordpress using Google App Engine and using this command to run the application, app_dir contains app.yaml, php.ini and wordpress:
google_appengine/dev_appserver.py app_dir/
and getting these errors:
File "/home/g1m/google_appengine/google/appengine/tools/devappserver2/php_runtime.py", line 222, in new_instance
self._check_environment(php_executable_path)
File "/home/g1m/google_appengine/google/appengine/tools/devappserver2/php_runtime.py", line 147, in _check_environment
'flag (%s) does not exist.' % php_executable_path)
_PHPBinaryError: The path specified with the --php_executable_path flag () does not exist.
I am trying to access the application using this url: localhost:8080 and get following error:
The path specified with the --php_executable_path flag () does not exist.
Kindly help me to solve this, what is the value of php_executable_path in LAMP as I am using UBUNTU12.04 operating system, is it /etc/php/cgi ?
Kindly let me know where I am doing wrong.
Make sure you install it first by doing:
sudo apt-get install php5-cgi
then locate it by running a search for php-cgi
sudo find / -name php-cgi
in my case i found it in : /usr/bin/php-cgi
I think the reason for this error is that GAE need to work with cgi not cli. The difference in them is that cli (command line interface) is for standalone application, not for web app (it didn't output html header by default). If php-cgi is installed , you can specify its path like this when you start dev server
<PATH_TO_SDK>app_devserver.py --php_executable_path=/usr/bin/php-cgi <your_project_name>
If you are not sure, you could search for it like dsb005 suggested.
If it's not installed... hmm... Maybe you miss this one on GAE document :
HP 5.4 is not packaged on most Linux distributions so it may be easiest to install it from source. On Debian-based Linux systems, you can use the following commands to install PHP 5.4 in such a way that it won't effect any other versions of PHP that you may have installed:
I suggest you follow the instruction on
https://developers.google.com/appengine/docs/php/gettingstarted/installinglinux and see if it works. It's always a pay off when you don't read the manual. I did that sometimes :(
I've already installed the RabbitMQ on my server and everything is working fine with it. I already tried to send and receive queued messages with a Java client and everything went perfect.
Now I need to install a PHP RabbitMQ client because I want to communicate a Java program with a PHP webpage, but this time I'm not beign so lucky.
I already followed the steps of the official webpage for this installation, specifically these steps:
# Download the rabbitmq-c library
hg clone http://hg.rabbitmq.com/rabbitmq-c/rev/3c549bb09c16 rabbitmq-c
cd rabbitmq-c
# Add the codegen requirement
hg clone http://hg.rabbitmq.com/rabbitmq-codegen/rev/f8b34141e6cb codegen
# Configure, compile and install
autoreconf -i && ./configure && make && sudo make install
And actually on the console I can see that it was "installed" without any problems. But when I try to open any AMQP Connection I get this error:
Fatal error: Class 'AMQPConnection' not found
Actually if I use the phpinfo(); command I can't see anything related to an AMQP module (like in this question). So I think that it may be a problem with the installation but I tried reinstalling it two times and it keeps saying that everything went well.
Have anyone crossed with this problem too?
Solved it..
The module wasn't being loaded in the right php.ini file. Just added extension=amqp.so at the end of the right php.ini file and restarted Apache.