php текущая папка скрипта

getcwd

(PHP 4, PHP 5, PHP 7, PHP 8)

getcwd — Получает имя текущего рабочего каталога

Описание

Возвращает имя текущего рабочего каталога.

Список параметров

У этой функции нет параметров.

Возвращаемые значения

Возвращает текущий рабочий каталог в случае успешного выполнения или false в случае ошибки.

Примеры

Пример #1 Пример использования getcwd()

Результатом выполнения данного примера будет что-то подобное:

Смотрите также

User Contributed Notes 19 notes

getcwd() returns the path of the «main» script referenced in the URL.

dirname(__FILE__) will return the path of the script currently executing.

I had written a script that required several class definition scripts from the same directory. It retrieved them based on filename matches and used getcwd to figure out where they were.

Didn’t work so well when I needed to call that first script from a new file in a different directory.

I use this code to replicate the pushd and popd DOS commands in PHP:

«On some Unix variants, getcwd() will return FALSE if any one of the parent directories does not have the readable or search mode set, even if the current directory does.»

Just so you know, MacOS X is one of these variants (at least 10.4 is for me). You can make it work by applying ‘chmod a+rx’ to all folders from your site folder upwards.

PHP4 returns /tmp
PHP5 returns /

Something to be aware of.

This is a function to convert a path which looks something like this:

To a proper directory path:

//saves our current working directory to a variable
$oldcwd = getcwd ();
//changes the directory to the one to convert
//$path is the directory to convert (clean up), handed over to the //function as a string

if you link your php to /bin/linkedphp and your php is at for ex /home/actual.php

when you run linkedphp in somewhere in your filesystem,
getcwd returns /bin instead of working dir,

solution: use dirname(__FILENAME__) instead

Some server’s has security options to block the getcwd()

Take care if you use getcwd() in file that you’ll need to include (using include, require, or *_once) in a script located outside of the same directory tree.

example:
//in /var/www/main_document_root/include/MySQL.inc.php
if ( strpos ( getcwd (), ‘main_’ )> 0 ) <
//code to set up main DB connection
>
?>

//in home/cron_user/maintenance_scripts/some_maintenance_script.php
require_once ( ‘/var/www/main_document_root/include/MySQL.inc.php’ );
?>

In the above example, the database connection will not be made because the call to getcwd() returns the path relative to the calling script ( /home/cron_user/maintenance_scripts ) NOT relative to the file where the getcwd() function is called.

A very simple workaround to regain the behaviour you’re used to from your «ordinary» webpage scripting is to include something like that at the beginning of your script:

// Note: all pathes stored in subsequent Variables end up with a DIRECTORY_SEPARATOR

// how to store the working directory «from where» the script was called:
$initial_cwd = preg_replace ( ‘

// how to switch symlink-free to the folder the current file resides in:
chdir ( dirname ( realpath ( __FILE__ ) ) );

// how to get a path one folder up in any case :
$my_parent_folder = preg_replace ( ‘

Источник

Php текущая папка скрипта

There is no way to implement a backwards compatible __DIR__ in versions prior to 5.3.0.

A lot of notes here concern defining the __DIR__ magic constant for PHP versions not supporting the feature. Of course you can define this magic constant for PHP versions not yet having this constant, but it will defeat its purpose as soon as you are using the constant in an included file, which may be in a different directory then the file defining the __DIR__ constant. As such, the constant has lost its *magic*, and would be rather useless unless you assure yourself to have all of your includes in the same directory.

Concluding: eye catchup at gmail dot com’s note regarding whether you can or cannot define magic constants is valid, but stating that defining __DIR__ is not useless, is not!

If you’re using PHP with fpm (common in this day and age), be aware that __DIR__ and __FILE__ will return values based on the fpm root which MAY differ from its actual location on the file system.

This can cause temporary head-scratching if deploying an app where php files within the web root pull in PHP files from outside of itself (a very common case). You may be wondering why __DIR__ returns «/» when the file itself lives in /var/www/html or whathaveyou.

You might handle such a situation by having NGINX explicitly add the necessary part of the path in its fastcgi request and then you can set the root on the FPM process / server / container to be something other than the webroot (so long as no other way it could become publicly accessible).

Hope that saves someone five minutes who’s moving code to FPM that uses __DIR__.

Источник

Что делает «Волшебная» константа __DIR__

3 ответа 3

Это директория того файла, в котором в данный момент исполняется код:

__FILE__ аналогичным образом вернет вам путь до исполняемого в данный момент файла (т.е. basename(__FILE__) === __DIR__ )

__DIR__ возвращает директорию выполняемого скрипта.

__DIR__ вернет путь папки в которой находится это скрипт, /usr/www/site/html

Если вы поставите свой скрипт на cron и у вас пути будут без константы DIR и аналогов, то скрипт не найдёт нужные файлы. хотя при ручном запуске всё будет ок.

Похожие

Подписаться на ленту

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.9.30.40353

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Источник

Абсолютные и относительные пути в PHP

Чем отличаются пути в PHP и URL

Когда мы смотрим любимый фильм или сериал, мы видим только готовый продукт.

А за кадром существует совсем другой, невидимый для нас мир: стилисты и гримёры, искусственные декорации, наложение спецэффектов и многое другое.

Вполне вероятно, что и такой папки там тоже нет, а все URL адреса обрабатываются одним единственным PHP файлом.

Новички часто путают пути к реальным файлам с URL адресами. Сейчас я разберу пару таких ошибок, на примере которых можно будет прочувствовать разницу.

Ошибка №1: Подстановка физического пути в URL

Это неправильно. Браузер не может видеть реальную файловую структуру сервера. Он не видит никаких дисков D, он видит только URL адреса.

Правильная ссылка выглядит так (разницу объясню чуть позже):

Ошибка №2: Подключение скриптов по URL

Иногда новички пытаются подключить физический файл по его URL:

Это неправильно. Во-первых, подключится не сам скрипт, а результат его работы. Во-вторых, подключать какие-то файлы через URL вообще идея очень опасная.

Абсолютный путь в PHP

Как видите, это полный путь от корня диска до конкретного файла или папки. Начинается со слеша или буквы диска (Windows).

Получить абсолютный путь скрипта можно с помощью магической константы __FILE__ :

Для получения абсолютного пути к папке, в которой находится скрипт, есть магическая константа __DIR__ :

Как этим пользоваться. Допустим, у нас в корне сайта лежат файлы index.php и config.php и мы хотим подключить второй в первый.

Если мы хотим подключить config.php по его абсолютному пути, есть два способа сделать это:

Поскольку константа __DIR__ не добавляет слеш после последней папки, мы указываем его вручную.

Относительный путь в PHP

Далее PHP попытается найти файл в папке текущего рабочего каталога.

Например, если мы в index.php подключили файл scripts/script.php, а в этом самом script.php уже пытаемся подключить файл по относительному пути, тогда поиск файла произойдёт и в папке scripts тоже.

Именно по этой причине я призываю тебя отказаться от использования относительных путей в PHP.

Кому-то из практикующих разработчиков эта фраза может не понравиться, но я считаю это единственным разумным решением.

Тем более нет ничего сложного в добавлении константы __DIR__ перед именем скрипта, что автоматически сделает путь абсолютным.

Абсолютный путь в URL

Второй и третий варианты удобны тем, что при миграции с http на https и обратно все ссылки автоматически сменят протокол, не нужно будет бегать по всему сайту и менять вручную.

Лично я практически всегда использую третий вариант, кроме случаев, когда нужно указать ссылку на другой поддомен (blog.site.ru, shop.site.ru и т.д.).

Относительный путь в URL

Относительные пути в URL указываются без слеша в начале ссылки, например:

Относительные пути в URL более предсказуемы, чем в PHP. Но я рекомендую использовать их только там, где это действительно необходимо.

Чаще всего их использование приводит к путанице. И вот пара типичных проблем, с которыми часто сталкиваются новички.

Ошибка №1: относительные пути к стилям, скриптам и другим файлам

Представим, что мы решили подключить стили к нашему сайту:

Разработчик указывает относительный URL style.css и видит, что всё работает. По крайней мере, на главной странице.

Ошибка №2: Рекурсия в ссылках

При использовании относительных путей есть риск случайно создать на сайте бесконечные ссылки. Вот один из таких способов:

Для работы данного кода должна быть настроена единая точка входа.

Текущий и родительский каталоги

Помимо указания конкретных папок, мы также можем добавить в путь указание «перейти на папку выше», например:

В коде выше мы подключим файл config.php, который находится не в текущей папке, а в родительской. С абсолютными путями это тоже работает:

И с URL-адресами тоже:

Также мы можем указать ссылку на текущий каталог, что бывает актуально в некоторых операционных системах:

Источник

PHP для начинающих. Подключение файлов

В продолжении серии «PHP для начинающих», сегодняшняя статья будет посвящена тому, как PHP ищет и подключает файлы.

Для чего и почему

PHP это скриптовый язык, созданный изначально для быстрого ваяния домашних страничек (да, да изначально это же был Personal Home Page Tools), а в дальнейшем на нём уже стали создавать магазины, социалки и другие поделки на коленке которые выходят за рамки задуманного, но к чему это я – а к тому, что чем больше функционала закодировано, тем больше желание его правильно структурировать, избавиться от дублирования кода, разбить на логические кусочки и подключать лишь при необходимости (это тоже самое чувство, которое возникло у вас, когда вы читали это предложение, его можно было бы разбить на отдельные кусочки). Для этой цели в PHP есть несколько функции, общий смысл которых сводится к подключению и интерпретации указанного файла. Давайте рассмотрим на примере подключения файлов:

Если запустить скрипт index.php, то PHP всё это будет последовательно подключать и выполнять:

Когда файл подключается, то его код оказывается в той же области видимости, что и строка в которой его подключили, таким образом все переменные, доступные в данной строке будут доступны и в подключаемом файле. Если в подключаемом файле были объявлены классы или функции, то они попадают в глобальную область видимости (если конечно для них не был указан namespace).

Если вы подключаете файл внутри функции, то подключаемые файлы получают доступ к области видимости функции, таким образом следующий код тоже будет работать:

Особенностью подключения файлов является тот момент, что при подключении файла парсинг переключается в режим HTML, по этой причине любой код внутри включаемого файла должен быть заключен в PHP теги:

Если у вас в файле только PHP код, то закрывающий тег принято опускать, дабы случайно не забыть какие-нить символы после закрывающего тега, что чревато проблемами (об этом я ещё расскажу в следующей статье).

А вы видели сайт-файл на 10 000 строк? Аж слёзы на глазах (╥_╥)…

Функции подключения файлов

Как уже было сказано выше, в PHP существует несколько функций для подключения файлов:

В действительности, это не совсем функции, это специальные языковые конструкции, и можно круглые скобочки не использовать. Кроме всего прочего есть и другие способы подключения и выполнения файлов, но это уже сами копайте, пусть это будет для вас «задание со звёздочкой» 😉

И будем его подключать несколько раз:

Результатом выполнения будет два подключения файла echo.php:

Существует ещё парочка директив, которые влияют на подключение, но они вам не потребуются — auto_prepend_file и auto_append_file. Эти директивы позволяют установить файлы которые будут подключены до подключения всех файлов и после выполнения всех скриптов соответственно. Я даже не могу придумать «живой» сценарий, когда это может потребоваться.

Где ищет?

Если при подключении файла вы прописываете абсолютный путь (начинающийся с «/») или относительный (начинающийся с «.» или «..»), то директива include_path будет проигнорирована, а поиск будет осуществлён только по указанному пути.

Возможно стоило бы рассказать и про safe_mode, но это уже давно история (с версии 5.4), и я надеюсь вы сталкиваться с ним не будете, но если вдруг, то чтобы знали, что такое было, но прошло.

Использование return

Занимательные факты, без которых жилось и так хорошо: если во включаемом файле определены функции, то они могут быть использованы в основном файле вне зависимости от того, были ли они объявлены до return или после

Написать код, который будет собирать конфигурацию из нескольких папок и файлов. Структура файлов следующая:

При этом код должен работать следующим образом:

Автоматическое подключение

Конструкции с подключением файлов выглядят очень громоздко, так и ещё и следить за их обновлением — ещё тот подарочек, зацените кусочек кода из примера статьи про исключения:

Первой попыткой избежать подобного «счастья» было появление функции __autoload. Сказать точнее, это была даже не определенная функция, эту функцию вы должны были определить сами, и уже с её помощью нужно было подключать необходимые нам файлы по имени класса. Единственным правилом считалось, что для каждого класса должен быть создан отдельный файл по имени класса (т.е. myClass должен быть внутри файла myClass.php). Вот пример реализации такой функции __autoload() (взят из комментариев к официальному руководству):

Класс который будем подключать:

Файл, который подключает данный класс:

Теперь о проблемах с данной функцией — представьте ситуацию, что вы подключаете сторонний код, а там уже кто-то прописал функцию __autoload() для своего кода, и вуаля:

Ну более-менее картина прояснилась, хотя погодите, все зарегистрированные загрузчики становятся в очередь, по мере их регистрации, соответственно, если кто-то нахимичил в своё загрузчике, то вместо ожидаемого результата может получится очень неприятный баг. Чтобы такого не было, взрослые умные дядьки описали стандарт, который позволяет подключать сторонние библиотеки без проблем, главное чтобы организация классов в них соответствовала стандарту PSR-0 (устарел уже лет 10 как) или PSR-4. В чём суть требований описанных в стандартах:

Различия этих двух стандартов, лишь в том, что PSR-0 поддерживает старый код без пространства имён (т.е. до версии 5.3.0), а PSR-4 избавлен от этого анахронизма, да ещё и позволяет избежать ненужной вложенности папок.

Благодаря этим стандартам, стало возможно появление такого инструмента как composer — универсального менеджера пакетов для PHP. Если кто пропустил, то есть хороший доклад от pronskiy про данный инструмент.

PHP-инъекция

Ещё хотел рассказать о первой ошибки всех, кто делает единую точку входа для сайта в одном index.php и называет это MVC-фреймворком:

Смотришь на код, и так и хочется чего-нить вредоносного туда передать:

Вторая «стоящая» мысль, это проверка на нахождение файла в текущей директории:

Третья, но не последняя модификация проверки, это использование директивы open_basedir, с её помощью можно указать директорию, где именно PHP будет искать файлы для подключения:

Будьте внимательны, данная директива влияет не только на подключение файлов, но и на всю работу с файловой системой, т.е. включая данное ограничение вы должны быть уверены, что ничего не забыли вне указанной директории, ни кешированные данные, ни какие-либо пользовательские файлы (хотя функции is_uploaded_file() и move_uploaded_file() продолжат работать с временной папкой для загруженных файлов).

Какие ещё возможны проверки? Уйма вариантов, всё зависит от архитектуры вашего приложения.

Хотел ещё вспомнить о существовании «чудесной» директивы allow_url_include (у неё зависимость от allow_url_fopen), она позволяет подключать и выполнять удаленный PHP файлы, что куда как опасней для вашего сервера:

Увидели, запомнили, и никогда не пользуйтесь, благо по умолчанию выключено. Данная возможность вам потребуется чуть реже, чем никогда, во всех остальных случаях закладывайте правильную архитектуру приложения, где различные части приложения общаются посредством API.

В заключение

Данная статья — основа-основ в PHP, так что изучайте внимательно, выполняйте задания и не филоньте, за вас никто учить не будет.

Это репост из серии статей «PHP для начинающих»:

Источник