Witam, że tak się skromnie spytam czy PHP w wersji 7 dostępny jest w wersji konsolowej? Niby podpowiada, że jest tylko 52., 5.3 i 5.4... a nie 7. Ale jak się wpisze... Kod: [...@... 18:20 ~/public_html/.../php-softquota]$ php -v Please run one of commands: php52-cli php53-cli php54-cli -v [...@... 18:22 ~/public_html/.../php-softquota]$ php7-cli -v PHP 7.0.3 (cli) (built: Jun 13 2016 14:15:43) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies [...@... 18:22 ~/public_html/.../php-softquota]$
wiem tylko, że od 07.02.2016 można włączać PHP w wersji 7 również przez Panel.home.pl - https://pomoc.home.pl/baza-wiedzy/nowy-interpreter-php-7/ Sprawdzam u administratorów dlaczego nie jest proponowany w wersji konsolowej przy zapytaniu php -v QA-28847 - dam znać w tym temacie na forum, gdy to skonsultuję.
Dostałem potwierdzenie, że odpowiedź, którą otrzymujesz od konsoli to tylko ładniejsza wersja "Unknown command". Tak czy inaczej administratorzy potwierdzili mi, że warto zastanowić się nad pokazywaniem nowszych wersji (dodałem jako sugestię: FEEDBACK-732). Dla potomnych, którzy dotrą do tego tematu w przyszłości, warto napisać, że pomiędzy wersją PHP włączaną w Panelu home.pl, a tą wersją PHP włączaną za pomocą konsoli różnice są następujące: po włączeniu wersji dajmy na to PHP 5.6, webserver używa tej właśnie wersji do "wykonywania" stron, opcje ustawione (np. inna wersja PHP) w Panelu home.pl nie mają wpływu na wersje cli php.
Poprawimy ten komunikat. Dodamy kolejne wersje PHP cli i dodamy je do tego komunikatu. Dostałem potwierdzenie od kierownika produktu i odpowiednie zlecenie (QA-28937) zostało już przesłane do naszych administratorów.
no dobra, odpaliłem skrypt, który wymaga PHP 7 poleceniem php7-cli skrypt.php i się wszystko wykonało bez widocznych błędów. Gdy próbowałem to samo z php56-cli to rzucił błędami, że wersja nie ta. To jak to jest z tym? Bo rozumiem, że oficjalnie PHP w tej wersji dla linii poleceń nie jest dostępne.
@LorK napiszę w tym temacie w momencie, gdy nasi administratorzy załatwią tę sprawę po naszej stronie. Prace po naszej stronie nie zostały zakończone, gdy otrzymam potwierdzenie, dam znać (mam ustawione powiadomienie, jak przy innym zgłoszonym temacie - nie zapomnę).
Można wszystko sprawdzić w konsoli poleceniem "type". Na serwerach współdzielonych home.pl komenda php jest zwykłym aliasem do komunikatu tekstowego: type php php is aliased to `echo -e '\nPlease run one of commands: php52-cli php53-cli php54-cli\n'' Z reguły - defaultowo instalacja PHP, np. na VPS-ie sprawia, iż polecenie "php" prowadzi do konkretnej binarki, gdzie znajduje się określony interpreter php. W przypadku home.pl zastosowano inne rozwiązanie - stąd alias, aby użytkownik wiedział, którą komendę wydać, aby wykonać skrypt. Polecenia php5x-cli prowadzą do konkretnej binarki; type php54-cli php54-cli is /usr/local/bin/php54-cli i wywołują skrypt z użyciem danego interpretera. Po prostu masz na serwerze kilka binarek - od 5.2 do 7.0. --- Domyślnie 'php -v' też Ci zwróci tekst (jak wyżej), bo tam jest zwykłe "echo" - nie ma parametrów. Natomiast możesz sobie ten alias sam usunąć, zrobić dowiązanie symboliczne, zapisać ustawienia własne w .bash_profile i sprawić, iż komenda php doprowadzi Cię poprzez odpowiednią ścieżkę $PATH do któregoś interpretera. Innymi słowy wpisując php będziesz wywoływał skrypt interpreterem np. w wersji 7.0. Nadpiszesz ustawienia domyślne. To zresztą jest często dość przydatne, ponieważ część instalatorów - np. framework Laravel (z poziomu Composera) korzysta z automatycznych skryptów, które szukają polecenia 'php' - jeśli takowe nie prowadzi do binarki - skrypt instalacyjny się wysypuje - dlatego tak przydatne są wówczas dowiązania symboliczne.
@Stau dziękuję za rzeczowy wykład. Miałem właśnie jakiś problem z Composerem. Dało się to jakimś przełącznikiem obejść by się odpaliło na 56. Przy drugiej instalacji spróbowałem php7-cli i poszło bez zająknięcia Dlatego dziwi mnie to co napisał @Mariusz, że nie ma takiego polecenia
@Stau dziękuję za rzeczową odpowiedź w sprawie dowiązań symbolicznych (zdecydowanie zabrakło tego w mojej odpowiedzi). Potwierdzam, że komunikat php -v jest tylko aliasem do komunikatu tekstowego. Przepraszam za niezbyt precyzyjne określenie. W home.pl nie korzystamy z polecenia php jako alias dla konkretnej wersji z następującego ważnego powodu (jest ich więcej, ale to jest w sumie najważniejszy powód): zmiana aliasu na wyższą wersję, mogłaby i najprawdopodobniej popsułaby skrypty klientów, którzy oparli się na aliasie. W ten sposób "zmuszamy" użytkowników do określenia jakiej wersji PHP chcą używać.
Podam może konkretny przykład. Tworzymy plik .bash_profile - wpisujemy w nim dwa wiersze: Kod: unalias php PATH="$HOME/public_html/bin:$PATH" Plik musi być dodany na tym samym poziomie, co katalogi "public_html" czy "backup". W katalogu "public_html" tworzymy katalog "bin" [mkdir bin]. Następnie przechodzimy do tegoż katalogu i tam tworzymy dowiązanie symboliczne (miękkie): Kod: ln -s /usr/local/bin/php7-cli php Efekt będzie następujący: ~/public_html/bin]$ ls -la total 8 drwxr-xr-x 2 serwerXXXX serwerXXXX 4096 Aug 29 19:58 . drwx--x--x 24 serwerXXXX home_pl 4096 Aug 11 09:21 .. lrwxrwxrwx 1 serwerXXXX serwerXXXX 23 Jun 24 20:26 php -> /usr/local/bin/php7-cli ----- Teraz wywołanie w konsoli polecenia php sprawi, iż odwołamy się do interpretera php w wersji 7.0. Dzięki temu instalacja Laravela zakończy się powodzeniem (z poziomu Composera).
@Stau, opis konkretny. Mi się nie chciało linkować. Za pierwszym razem odpaliłem to na php56-cli z jakimś parametrem forsującym/ignorującym by się dało zainstalować. Za drugim razem, z ciekawości, wpisałem php7-cli [skrypt] i poszło bez zająknięcia
Mnie przy instalacji Laravela z poziomu Composera skrypt instalacyjny wysypywał się z uwagi na przekraczanie jakichś tam parametrów bezpieczeństwa - limitów dla hostingu współdzielonego. Chodziło o alokację pamięci, jeśli dobrze pamiętam. Tak działo się, gdy odpalałem skrypt z poziomu interpretera 5.X. Wszystko skończyło się "happy end-em" dopiero, gdy zastosowałem PHP 7.0. Skrypt poszedł do końca . Za każdym razem stosowałem metodę jak powyżej (symlinki).
@LorK @Stau dostałem potwierdzenie, że zmiany zostały wdrożone (dodanie informacji o wersjach/dodanie wersji 7), ale może minąć jeszcze trochę czasu, aż się rozejdą po wszystkich maszynach. Ustawiam temat jako rozwiązany.