[PHP][ЖЖ] Горлопаны! Свистуны! Мазепы! Жуки на заборе!..

http://69.147.83.196/bug.php?id=45421&edit=1

Для удобства

Спасибо

мне бы вот ни разу в голову не пришло завязывать логику на значение __FILE__. это надо каким-то особенно перверсивным умом обладать, что бы такое выдумать. так что, ссзб.

include dirname(__FILE__)."/../somelib/xxx.php";

Другого вменяемого способа, если включающий файл сам инклуднут откуда-нибудь, не существует.

> Другого вменяемого способа, если включающий файл сам инклуднут откуда-нибудь, не существует.

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

ini_set("include_path", "<bla-bla>");
require_once "xxx.php";

не?

>Здесь древний баг

Submitted: 2 Jul 2008
и это по-твоему древний баг? После эпических багов тормозиллы это детский лепет.

>на который я напоролся не далее как сегодня
при каких действиях? Насколько я понял там речь про хардлинки. Или грабли срабатывают, даже если банально скопировать/переименовать?

> при каких действиях? Насколько я понял там речь про хардлинки. Или грабли срабатывают, даже если банально скопировать/переименовать?

Есть проект. У него там своя иерархия:

a/
a/index.php
a/blabla.php
a/includes/
a/includes/xxx.php
a/includes/yyy.php
a/includes/local/config.php

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

Надо было сделать так, чтобы у меня было пять разных инсталляций проекта с одной кодовой базой, чтобы все они смотрели в разные БД. Но чтобы после изменений, скажем, в yyy.php, мне не надо было его копировать пять раз.

Короче, использовал я для этого сперва lndir — все симлинками, а config.php настоящий. Но не тут-то было... Апач-то, когда разрешает симлинк, то и dirname(__FILE__), и getcwd() возвращают не директорию, в которой симлинк лежит, а ту, где настоящий файл. Это поведение не настраивается. Пришлось бросить.

Тогда я решил наделать хардлинков, тогда апач с пэхапой вместе обманываются на раз, но eAccelerator объявил, что так не играет, и засегфолтился.

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

То бишь, у этого WTF уровней достаточно много, но вот так вот отрицать очевидное — это подлейшее хамство. Тебе говорят — пока это, глядь, константа, на уровне opcode cache ничего не исправить. Если это не будет константа, то исправлять ничего не надо будет. В ответ — PHP работает, как задумано, исправляйте opcode cache. Задумано?! Батеньки, я точно сделал правильный выбор, перейдя для своего проектика на питон, хотя мне с непривычки придется чуть дольше враскоряку постоять.

К счастью, eAccelerator на этой вот именно машине некритичен и я смог его временно отрубить. Все работает, до следующих граблей.

ССЗБ. Перверт тут ты, ибо надо ж до такого додуматься.
Алсо $_SERVER['SCRIPT_FILENAME']

> Алсо $_SERVER['SCRIPT_FILENAME']

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

То бишь если a.php входит в b.php, он _должен_ знать, что он a.php и откуда взят. $_SERVER['SCRIPT_FILENAME'] этого не скажет.

Иначе говоря, ты либо читать не умеешь, либо кретин, либо и то, и другое.

Ути, какие мы грозные. Зубки не поломай смотри.
В описании к обоим багам написано: кешируете compile-time константы - ССЗБ.
APC вот умеет различать какой файл - где, и кешировать отдельно. Если создатели eAccelerator об этом не позаботились - это не проблемы разрабов пхп.

>Надо было сделать так, чтобы у меня было пять разных инсталляций проекта с одной кодовой базой, чтобы все они смотрели в разные БД. Но чтобы после изменений, скажем, в yyy.php, мне не надо было его копировать пять раз.

тебе не кажется, что это проще решить с помощью системы контроля версий?

> тебе не кажется, что это проще решить с помощью системы контроля версий?

Как именно? У меня сейчас сеанс одновременной игры: пилю генерируемый SQL-запрос (генератор пилить проще, чем результат), надо смотреть на трех слепках разных продакшеновских баз — улучшило ситуевину или ухудшило, с минимальными задержками на переключение контекста.

Пока что вырубание eAccelerator и хардлинки решили.

>Как именно?

пять локальный копий-инсталляций, config.php в .{hg|git}ignore, или я чего-то не понимаю.

т.е. вы мучаете систему сразу на продакшене? =)
жестоко..

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

__FILE__ использую _очень_ редко только для переопределения методов, возвращающих файл класса, если потомки должны знать положение родителя, и всё.

Даже в debug-выводе __FILE__ нигде не использую, вместо этого - debug_backtrace();

...

>Короче, в кучу смешано и контроллеры, и библиотеки, и объем этого достаточно велик, чтобы забыть на ближайшее полугодие о тотальном рефакторинге

Ну и что? Ты на продакшне, что ли, файлы ковыряешь? Если да - то без комментариев. Если нет - то обновляться будешь не каждые 5 минут и разок не страшно, если уж так припрёт, apc-демон передёрнуть.

>Надо было сделать так, чтобы у меня было пять разных инсталляций проекта с одной кодовой базой, чтобы все они смотрели в разные БД. Но чтобы после изменений, скажем, в yyy.php, мне не надо было его копировать пять раз.

Это делается пятью конфиг-файлами в пяти проектах.

...

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

Все настройки и расширения конкретных проектов - только внутри каталогов этих проектов.

Да, и во всём этом весьма наворочанная иерархия файлов, и взаимных инклудов. При чём есть код ядра, код сторонних разработчиков, код расширений и настроек хостинга, код конкретного проекта... И нигде почему-то даже мысли не возникало юзать __FILE__ :)

> т.е. вы мучаете систему сразу на продакшене? =)
> жестоко..

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

> У меня с одного и того же кода на одной машине до десятка проектов работает иногда :)

Так это у тебя. А у меня тяжкое наследие больного прошлого, и копий кода тоже надо пять :(

>А у меня тяжкое наследие больного прошлого, и копий кода тоже надо пять :(

У меня тоже на www.aviaport.ru местами до сих пор тоже тяжёлое наследие больного прошлого :D И до сих пор в ряде мест ещё не переписано - работает, и ладно.

...

Обычно, чтобы большой заставить чужой код вести себя по-своему, нужно не так уж много правок-костылей. Когда 5 копий кода - то это однозначно надо менять. Уйдёт не полгода, а неделя (это если случай совсем запущенный), зато потом вздохнёшь свободнее и сэконмишь уйму времени.

К большому сожалению, на этом проекте приоритеты расставляю не я :)