I'm trying to do a simple drush dl drupal but I got this error:
➜ drush dl drupal
copy(/tmp/drush_tmp_1499421442_595f5b0280292/tar: Failed to set default locale): failed to open stream: No such file or directory filesystem.inc:268 [warning]
Project drupal (8.3.5) could not be downloaded to /xxx/test/drupal-8.3.5. [error]
I tryed to chmod -R 777 /tmp (/private/tmp) but nothing change. How to fix it?
Fixed by adding these lines in my ~/.bashrc
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
export LC_COLLATE=C
export LC_CTYPE=en_US.UTF-8
Then source ~/.bashrc
Related
I'm discovering symfony and on a way to develop a web app. I just installed it (a couple of days now) but yet I can't have access to it through my terminal. It shows command not found is the principal message I get when I try. checked php and composer, they are all ok. But still don't have access to symfony.
Tried using this code
"hardpro$ mv /usr/hardpro/bin/composer.phar /usr/hardpro/bin/composer" to change the directory but yet, nothing.
ESOservices:~ hardpro$ documents/symfony
-bash: documents/symfony: No such file or directory
ESOservices:~ hardpro$ documents/symfony new
-bash: documents/symfony: No such file or directory
ESOservices:~ hardpro$ cd esoServices
-bash: cd: esoServices: No such file or directory
ESOservices:~ hardpro$ cd symfony
-bash: cd: symfony: No such file or directory
ESOservices:~ hardpro$ symfony new --full my_project
-bash: symfony: command not found
ESOservices:~ hardpro$ mv /usr/local/bin/composer.phar /usr/local/bin/composer
mv: rename /usr/local/bin/composer.phar to /usr/local/bin/composer: No such file or directory
ESOservices:~ hardpro$ mv /usr/hardpro/bin/composer.phar /usr/hardpro/bin/composer
mv: rename /usr/hardpro/bin/composer.phar to /usr/hardpro/bin/composer: No such file or directory
You might need to define the PATH. Run this command before you want to run the symfony command.
export PATH="$HOME/.symfony/bin:$PATH"
Then you should be able to run a command like symfony server:start, but you would need to run the export every time you reopen your terminal.
To solve it permanently, you would need to add this command to your bash profile.
It seems like you have an error with your installation, you should install it again.
To install symfony : https://symfony.com/download
To install composer : https://getcomposer.org/download
To use it globally : https://getcomposer.org/doc/00-intro.md#globally
You have to run the command mv composer.phar /usr/local/bin/composer in the same folder where you run the install composer commands.
According to this post and with local installation of Drush 9 as adviced by the official website (not globally installed), I put my Drush8 alias file into: ~/.drush/sites, in addition of the ~/www/domain/sited8/drush/sites default folder. And I edited the ~/.drush/drush.yml file to add my other path to alias files.
Then I run ~ $ drush site:alias-convert and get:
Absolute path to a directory for writing new alias files [~/www/domain/sited8/drush/sites]: !!
Then drupal ccreate converted files into this folder. It seem to ignore my other folder..
Actually I get only one website but I will add others, so I want to have my alias files into a root folder instead of a drupal website folder (it will not be a multisite install).
So why drush doesn't look an dwork into my ~/.drush/sites folder ?
EDIT: after convertion, I move files to ~/.drush/sites then with drush sa I get a list like :
'#sited8ce.prod':
root: ~/www/celony/sited8
uri: 'https://www.lycee-celony.com/'
'#sited8mg.dev':
root: ~/www/mgasquet/sited8
uri: 'http://d8-lycee-marie-gasquet.eu'
but when I try to use one of them I get partial status info:
$ drush #sited8ce.prod status
PHP binary : /php/7.2.14/bin/php
PHP config : ~/admin/config/php/php.ini
PHP OS : Linux
Drush script : ~/www/mgasquet/sited8/vendor/drush/drush/drush
Drush version : 9.7.1
Drush temp : /tmp
Drush configs : ~/.drush/drush.yml
~/www/mgasquet/sited8/vendor/drush/drush/drush.yml
Drush is locally installed in both websites but the drush folder is only present on one..I don't understand the logic here..
Because alias doesn't work:
~ $ drush #sited8ce.prod pml | grep goo
Command pml was not found. Pass --root or a #siteAlias in order to run Drupal-specific commands.
ZSH shell shows Git prompt status (master [?]) even if a directory isn't a git directory.
What could be the problem? Thanks in advance.
My .zshrc file:
export PATH=$HOME/bin:/usr/local/bin:$PATH
export ZSH=/Users/m3rkus/.oh-my-zsh
ZSH_THEME="spaceship"
plugins=(git)
source $ZSH/oh-my-zsh.sh
One of the higher level folder has probably a .git folder in it.
You can use #Adaephon suggested command to find where it is:
git rev-parse --show-toplevel
I am attempting to install Drupal 7.34 on RHEL and I continue to run into issues with permissions on sites/default/files. I've searched all over for a solution, but nothing has helped.
Here are the steps I am taking (with root access):
In /var/www/html I execute: drush dl drupal to download Drupal.
I then follow Drupal's install instructions (from /var/www/html):
mv drupal-7.34/* ./
mv drupal-7.34/.htaccess ./
mv drupal-7.34/.gitignore ./
cp sites/default/default.settings.php sites/default/settings.php
chmod a+w sites/default/settings.php
chmod a+w sites/default
cd ..
chown -R apache:apache html
In the browser, I navigate to http://myhost/install.php. In the "Verify requirements" step of the install process I receive the following error:
The directory sites/default/files does not exist.
So, I take then take the following steps:
mkdir html/sites/default/files
chmod a+w html/sites/default/files
chown apache:apache html/sites/default/files
When I attempt the install process I now get the following error:
The directory sites/default/files is not writable.
What am I missing here? The sites/default/files directory exists and is writable. Any guidance is much appreciated.
The solution I applied was more of a work-around, but I ended up using Drush to handle the entire installation rather than using it to download Drupal and manually configuring it from there.
I still don't know the answer to this "simple" error but I do know that before adding users or granting full permissions to a group one must know the name of the user running (owning) httpd. This is not always www-data
Also - my sites/default/files -is- in fact writable as is the case for just about everyone who posts this question. There is something seriously wrong with Drupal's install that it has this issue, that it is so prevalent and not addressed adequately by the code maintainers. Searched about twenty responses to this "very simple" problem and still none of the suggestions work. Opened up permissions entirely, chown the drupal installation files to the httpd daemon (apache) and group (www in my case)
These fixed it for me:
chmod 777 sites/default
chmod 777 sites/default/setting.php
It turns out the 'chmod a+w...' commands in the docs were not enough - the 777 includes 'x', making the items executable as well as writable.
I've recently installed PHPUnit on a Mac (10.8.3) (running PHP 5.4.7). When I attempt to a run a test phpunit testfile.php for example, I receive:
Warning: require_once(File/Iterator/Autoload.php): failed to open stream: No such file or
directory in /Users/myusername/pear/share/pear/PHPUnit/Autoload.php on line 64
Fatal error: require_once(): Failed opening required 'File/Iterator/Autoload.php'
(include_path='.:') in /Users/myusername/pear/share/pear/PHPUnit/Autoload.php on line 64
The file, /Users/myusername/pear/share/pear/File/Iterator/Autoload.php exists.
php.ini correctly lists the pear directories in the include path:
.:/php/includes:/usr/local/apache/lib/php:/Users/myusername/pear/share/pear/
Yet when I var_dump(get_include_path()); inside of the PHPUnit/Autoload.php file, it prints .: as if it's empty.
Dumping the value of php_ini_loaded_file instead, simply returns false.
Using php -i |grep php\.ini and php --ini only show one php.ini being used/loaded:
Configuration File (php.ini) Path => /usr/local/apache/lib
Loaded Configuration File => /usr/local/apache/lib/php.ini
I repeated the var_dumps of the include_path and the loaded_ini_file from a simple test.php file I ran from the command line and they print out the correct info. So something involved with phpunit is not loading the right/any php.ini.
I'm not using any configurations that are different than default - phpunit was just installed on this machine today.
Make sure the php.ini file you are using is the one loaded for cli php. At least on my install of PHP on Linux, I have two php.ini files, one at /etc/php/cgi-php5.4/php.ini, and the other at /etc/php/cli-php5.4/php.ini. If you change the cgi version, it won't by default affect the cli version, and would cause the include path to be empty.
Another place to check is the phpunit.xml file. It has a section to specify the include path. See here for options available. I'm not sure why phpunit would reset the path but this might be a way to solve the issue.
The solution was:
After running
`pear config-get php_bin` -i | grep -E Configuration\ File\|include_path
It showed that Pear was using a different ini path than php-cli was:
Configuration File (php.ini) Path => /etc
Loaded Configuration File => (none)
include_path => .: => .:
Turns out, Pear had been configured by the original/default Mac OS copy of PHP, not by the custom version I had installed later on.
A quick fix that may not be best long-term was to symlink the ini file it was trying to find:
sudo ln -s /usr/local/apache/lib/php.ini /etc/php.ini
Afterwards, phpunit FakeTest commands are work, and the tests run.
Eventually I need to re-install/re-configure Pear to work with the version of php I've loaded.